wa (G / Ç bekleniyor) en büyük komuttan

Çok ziyaretçinin olduğu bir forumum var, bazı günler sayı artırıcıları olmadan yük 40'a ulaşıyor. Aşağıdaki çıktıdan görebileceğiniz gibi, bekleme süresi yüksektir (% 57). bunun nedenini nasıl bulabilirim?
Sunucu yazılımı Apache, MySQL ve PHP'dir.

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

.

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

Disk etkinliğini bulmak için birkaç araç:

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

Ayrıca, ps auxfhangi işlemlerin yorumlanamayan disk uykuda olduğunu ( D) göreceksiniz çünkü G / Ç için bekliyorlar.

Bazı günlerde, sayı vizörlerinde artış olmadan yük 40'a yükselir.

Ayrıca bir yedekleme oluşturmak isteyebilir ve sabit sürücünün yavaşça çalışıp çalışmadığını görebilirsiniz. Bir sabit disk sürücüsü genellikle bitmeden önce yavaşlamaya başlar. Bu aynı zamanda yüksek yükü de açıklayabilir.

Yukarıdan gelen çıktılar, DBMS'nin G / Ç beklemelerinin çoğunu yaşadığını gösteriyor, bu nedenle veritabanı ayarlama sorunları araştırılmaya açık bir aday.

Bir veritabanı sunucusunda bekleyen G / Ç - özellikle yük çivilerinde - DBMS'nizin diske bağlı olabileceği (yani daha hızlı bir disk alt sistemine ihtiyaç duyabileceğiniz) veya bir ayarlama sorunu yaşayabileceğinin bir ipucudur. Muhtemelen, veritabanı sunucunuzu profillendirmeye de bakmalısınız - yani, ne yaptığını ve ne zaman harcadığı sorgularını takip edin.

Veritabanı ayarlama sorunlarını teşhis etmek için bazı başlangıç ​​noktaları: -

• En fazla zaman alan sorguları bulun ve sorgu planlarına bakın. Olmaması gereken bir tablo taraması gibi tuhaf sorgu planları olup olmadığına bakın. Belki de veritabanı eklenmiş bir dizine ihtiyaç duyar.

• Uzun kaynak bekleme süreleri, bazı temel kaynak havuzunun genişletilmesi gerektiği anlamına gelebilir.

• Uzun G / Ç bekleme süreleri, daha hızlı bir disk alt sistemine ihtiyaç duyduğunuz anlamına gelebilir.

• Günlük ve veri hacimleriniz ayrı sürücülerde mi? Veri tabanı günlüklerinde çok sayıda küçük sıralı yazı vardır (temelde bir halka tamponu gibi davranırlar). Günlüklerinizle aynı diskleri paylaşan yoğun bir rasgele erişim iş yükünüz varsa, bu, günlüklemenin verimini orantısız şekilde etkiler. Bir veritabanı işleminin kayıt işlemlerini gerçekleştirebilmesi için diske yazılması gerekir, bu nedenle bu tüm sisteme bir tıkanıklık getirecektir.
  
  Bazı MySQL depolama motorlarının günlükleri kullanmadığına dikkat edin, bu durumda sizin için sorun olmayabilir.

Dipnot: Kuyruk sistemleri

Kuyruk sistemleri (verimlilik için istatistiksel bir model), sistem doygunluğa yaklaştıkça hiperbolik olarak yavaşlar. Yüksek seviyeli bir yaklaşım için,% 50 doymuş bir sistem ortalama kuyruk uzunluğuna 2 sahiptir.% 90 doymuş bir sistem 10 kuyruk uzunluğuna sahiptir,% 99 doymuş bir sistem 100 kuyruk uzunluğuna sahiptir.

Dolayısıyla, doygunluğa yakın bir sistemde, yükteki küçük değişiklikler bekleme sürelerinde büyük değişikliklere neden olabilir, bu durumda G / Ç'de geçirilen zaman olarak ortaya çıkar. Disk alt sisteminizin G / Ç kapasitesi neredeyse doymuşsa, yükteki küçük değişiklikler yanıt sürelerinde önemli değişikliklere neden olabilir.

Çalıştırın iotopveya atop -dDhangi işlemlerin yapıldığını görmek için. Daha straceyakından bakmak isterseniz kullanın .

Her iki ekranda da "mysqld" sorumludur.

O servetin ne yaptığını görmelisin ... hangi sorguları çalıştırıyorsun.

Bazı günlerde, sayı vizörlerinde artış olmadan yük 40'a yükselir.

Kullanıcıların yaptıkları, aslında orada bulunan sayı kadar önemli olabilir. Forumda arama yapmak gibi işlemler tek tek iş parçacığı veya iş parçacığı listesi yükleme ve görüntüleme işleminden daha zorlu olacaktır.

Ayrıca: Özel bir sunucuda mı yoksa VPS'de mi çalışıyorsun? Hizmetiniz özel bir sunucuda değilse, aynı ana bilgisayarda çalışan uygulamaların eylemleri, VM'nizin bir ana bilgisayarı paylaştığı VM'lerin G / Ç kaynağının bir payı için rekabet edeceği bir etkiye sahip olacaktır.

Diğerlerinin de belirttiği gibi, araçlar iotop, G / Ç yanıtlarını bekleyen hangi görevlerin yerine getirildiğini ve o sırada hangi dosyalara eriştiğini incelemenize yardımcı olacaktır.

Flip'in dediği gibi, sorun mysql'in yaptığı şeylerle ilgili gibi görünüyor.

Fiziksel belleğinizin yaklaşık yarısı şu anda G / Ç önbelleğe alma için kullanılıyor - forum yazılımı genellikle az sayıda satır döndüren, çok fazla eğri sıcak alan içeren, çok sayıda satır döndüren çok sayıda hızlı sorgu oluşturur; bu kadar bekleyin.

Milyonlarca satırı güncelleyen sorgular çalıştırırken sadece böyle CPU / disk kullanımını gördüm.

Yüksek yük ortalaması, G / Ç'nin doğrudan sonucudur.

Orada kötü kod olup olmadığını görmek için MySQL günlüğünüzü yükseltin / dizinleri değiştirmek yardımcı olacaktır. Tablolarınızı analiz etmeniz yardımcı olabilir (ancak büyük olasılıkla pek değil).

C.