Kategori arşivi: Sunucu Yönetimi

Duplex: Half

$ ethtool eth0 | grep Duplex
 Duplex: Half

ise farklı sunucularla iletişirken sorun yaşanabiliyor. Benim sorun yaşadığım durumda sunucu 1’den sunucu 2’ye giden isteklerin bazılarında iletişim problemleri oluştu.

SUNUCU A (ubuntu 14.04)

$ ethtool eth0
 Settings for eth0:
 Supported ports: [ TP ]
 Supported link modes: 10baseT/Half 10baseT/Full
 100baseT/Half 100baseT/Full
 1000baseT/Full
 Supported pause frame use: No
 Supports auto-negotiation: Yes
 Advertised link modes: 10baseT/Half 10baseT/Full
 100baseT/Half 100baseT/Full
 1000baseT/Full
 Advertised pause frame use: No
 Advertised auto-negotiation: Yes
 Speed: 100Mb/s
 Duplex: Half
 Port: Twisted Pair
 PHYAD: 1
 Transceiver: internal
 Auto-negotiation: on
 MDI-X: Unknown
 Supports Wake-on: g
 Wake-on: d
 Link detected: yes

SUNUCU B (ubuntu 14.04)
$ ethtool eth0

$ ethtool eth0
 Settings for eth0:
 Supported ports: [ TP ]
 Supported link modes: 10baseT/Half 10baseT/Full
 100baseT/Half 100baseT/Full
 1000baseT/Half 1000baseT/Full
 Supported pause frame use: No
 Supports auto-negotiation: Yes
 Advertised link modes: 10baseT/Half 10baseT/Full
 100baseT/Half 100baseT/Full
 1000baseT/Half 1000baseT/Full
 Advertised pause frame use: Symmetric
 Advertised auto-negotiation: Yes
 Link partner advertised link modes: 10baseT/Half 10baseT/Full
 100baseT/Half 100baseT/Full
 1000baseT/Full
 Link partner advertised pause frame use: Symmetric
 Link partner advertised auto-negotiation: Yes
 Speed: 1000Mb/s
 Duplex: Full
 Port: Twisted Pair
 PHYAD: 1
 Transceiver: internal
 Auto-negotiation: on
 MDI-X: off
 Supports Wake-on: g
 Wake-on: d
 Current message level: 0x000000ff (255)
 drv probe link timer ifdown ifup rx_err tx_err
 Link detected: yes

Sunucu A’nın Duplex’i Full yaptıktan sonra sorunlar düzeldi. Bunu yapmak için sunucu a’da izlenmesi gereken adımlar şunlar

$ vim /etc/network/interfaces

iface eth0 inet static

altına

post-up /sbin/ethtool -s eth0 speed 100 duplex full autoneg off

ekleyin ve reboot yapın.

MySQL temp table için ssd-tmpfs farkı

Sorgumuz bu;

SELECT SQL_NO_CACHE DISTINCT a.*, u.user_email, u.user_nicename, u.user_login, u.display_name FROM wp_bp_activity a LEFT JOIN wp_users u ON a.user_id = u.ID WHERE a.is_spam = 0 AND a.hide_sitewide = 0 AND a.type != ‘activity_comment’ ORDER BY a.date_recorded DESC LIMIT 0, 50

Bir çok join işleminde olduğu gibi bu sorguda da MySQL temp table oluşturuyor ve my.cnf da ayarladığınız tmpdir’a bu temp table’ı atıyor.

Ben sunucularımda ssd disk kullanıyorum. Bu sorguyu incelerken “Copying to tmp table” işleminin uzun sürdüğünü görerek bir çözüm aradım ve tmpdir olarak tmpfs kullanmanın bu işi hızlandırabileceğini ve nasıl tmpfs’e geçileceğini şurada gördüm ve uyguladım. Ubuntu kullanıyorsanız şuradaki yazıyı da okumalısınız.

tmpfs; dosyaları disk yerine ramde tutuyor ve haliyle işleminiz daha hızlı oluyor. Şimdi sonuçları paylaşıyorum.

tmpfs’den önce

Sorguyu 3 defa art arda çalıştırdım…

Screen Shot 2014-05-05 at 13.38.46 Screen Shot 2014-05-05 at 13.39.21 Screen Shot 2014-05-05 at 13.39.29

Sonra

Yine 3 defa art arda çalıştırdım.

Screen Shot 2014-05-05 at 13.39.47 Screen Shot 2014-05-05 at 13.39.57 Screen Shot 2014-05-05 at 13.42.09

Sonraki sonuçlarda da yine ortalama 1.5sn civarı sürdü. Benim ssd kullandığım sunucumda fark 0.2sn kadar oldu.