Назад | Перейти на главную страницу

Чрезвычайно высокие нагрузки, несмотря на кеширование

Хорошо, у меня есть хороший выделенный сервер под управлением CentOs 6 с 16 ГБ оперативной памяти, двумя ксеноновыми процессорами и т. Д. Однако я испытывал высокие нагрузки из-за mysql. В случайном порядке загрузка будет ниже 1.0, а время генерации страницы будет <30 мсек, и сайт работает плавно. Это примерно 100 одновременных пользователей, обслуживающих менее 200 страниц в минуту. Однако в 99% случаев он очень медленный и имеет сумасшедшие высокие нагрузки, обычно по крайней мере 4 раза из 100. У нас не было этой проблемы, раньше этот сервер мог обрабатывать 400 одновременных пользователей и 1000 страниц в минуту без нагрузки выше 1,5.

Первое, что я сделал, это реализовал кеширование базы данных в PHP с помощью ADOdb. Это немного помогло, но не решило проблему.

Я просмотрел весь Интернет и, кажется, не могу понять, что не так. Я попросил друга взглянуть, но он понятия не имел. Я попросил своего хозяина переключить нас на новую машину, та же проблема через несколько часов. Мы не должны перегружать трафик, который мы получаем.

Я начинаю думать, что это может иметь какое-то отношение к / tmp. После запуска tmpwatch --mtime --all 1 / tmp мне удалось на некоторое время восстановить нормальную нагрузку. Однако это не помогло снова после резких скачков нагрузки.

Если кто-нибудь знает, что не так, я был бы очень признателен. Я не уверен, что вы можете использовать в качестве показателей, но я включил некоторые, которые, как мне кажется, могут помочь.

'верхний' вывод:

top - 22:02:36 up 1 day, 23:39,  1 user,  load average: 4.01, 4.38, 4.50
Tasks: 233 total,   1 running, 231 sleeping,   0 stopped,   1 zombie
Cpu(s): 25.5%us,  2.0%sy,  0.0%ni, 70.5%id,  2.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  16331836k total, 16034868k used,   296968k free,   375472k buffers
Swap: 18546680k total,        0k used, 18546680k free, 14421512k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                        
31149 mysql     20   0 1589m  32m 6024 S 191.0  0.2   5:54.80 mysqld                                                        
27575 apache    20   0  312m  13m 3464 S  2.7  0.1   0:04.06 httpd                                                          
29427 apache    20   0  317m  18m 3484 S  2.7  0.1   0:02.76 httpd                                                          
25331 apache    20   0  311m  12m 3440 S  2.3  0.1   0:05.55 httpd                                                          
21331 apache    20   0  408m  15m 3676 S  2.0  0.1   0:08.57 httpd                                                          
24226 apache    20   0  314m  14m 3484 S  2.0  0.1   0:06.45 httpd                                                          
32352 apache    20   0  311m  12m 3424 S  2.0  0.1   0:01.01 httpd                                                          
32377 apache    20   0  312m  13m 3484 S  2.0  0.1   0:00.86 httpd                                                          
  774 apache    20   0  312m  12m 3108 S  1.7  0.1   0:00.11 httpd                                                          
28165 apache    20   0  406m  12m 3588 S  1.7  0.1   0:03.76 httpd                                                          
30516 apache    20   0  311m  12m 3476 S  1.7  0.1   0:02.04 httpd                                                          
31019 apache    20   0  313m  13m 3436 S  1.7  0.1   0:01.68 httpd                                                          
31020 apache    20   0  314m  15m 3484 S  1.7  0.1   0:01.71 httpd                                                          
  657 apache    20   0  311m  12m 3108 S  1.3  0.1   0:00.20 httpd                                                          
27731 apache    20   0  406m  12m 3572 S  1.3  0.1   0:03.69 httpd                                                          
28180 apache    20   0  313m  13m 3480 S  1.3  0.1   0:03.43 httpd                                                          
30565 apache    20   0  314m  14m 3488 S  1.3  0.1   0:02.07 httpd 

вывод 'df'

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg-root  461164576  45283168 392455568  11% /
tmpfs                  8165916         0   8165916   0% /dev/shm
/dev/sda1               247919     72922    162197  32% /boot
/dev/mapper/vg-tmp     1032088    137344    842316  15% /tmp

вывод 'iostat'

Linux 2.6.32-220.el6.x86_64 (domain redacted)   09/05/2012  _x86_64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.88    0.00    0.49    1.53    0.00   93.09

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda              18.03        98.46       787.86   17060770  136515216
dm-0             76.33        98.15       605.19   17006740  104862680
dm-1              0.00         0.02         0.00       3176          0
dm-2             22.78         0.21       182.06      35730   31546312

Есть два места, с которых можно начать диагностику:

  1. Проверьте, нуждается ли MySQL в настройке; mysqltuner - отличный автоматизированный инструмент для проверки вашей конфигурации (включая текущую статистику) на соответствие рекомендованной конфигурации.

  2. Посмотрите, сколько файлов в /tmp когда производительность низкая, и какая это файловая система, а также насколько «большой» каталог. Если он очень большой или в нем много файлов, вам может пригодиться его установка. tmpfs, что должно быть немного быстрее. (... или избегая слишком большого количества файлов. :)

Наиболее вероятная отправная точка - выяснить, вызывает ли ваша производственная нагрузка какие-либо проблемы с настройкой MySQLtuner.