В последнее время на нашем сервере возникла проблема с памятью. Несколько недель назад наш сервер загружался очень медленно. Доступ к электронной почте и веб-сайтам действительно занимал слишком много времени. Затем мы попросили техподдержку сервера перезагрузить сервер за нас. После перезагрузки все вернулось в норму. Мы подумали, что пришло время обновить оперативную память. Изначально на нашем сервере было всего 2 ГБ ОЗУ, поэтому мы увеличили его до 8 ГБ.
Мы думали, что проблема решена. Однако после обновления ОЗУ использование памяти становилось все выше и выше. Было похоже, что всегда достигается максимальное использование (например, 456,5 МБ свободно из 7,8 ГБ памяти). На следующий день сервер был полностью отключен, и нам пришлось попросить техподдержку перезагрузить сервер для нас снова. Каждый раз, когда мы сталкиваемся с проблемой, мы должны просить обслуживающий персонал перезагрузить сервер за нас. По словам сотрудников службы поддержки, если они получат доступ к SQL, память вернется в нормальное состояние. Но если они на нем снова, память снова станет выше. Итак, они подозревают, что проблема в SQL-запросе.
Я хочу спросить, действительно ли проблема возникает из-за SQL-запроса? Или это была аппаратная проблема? Если это SQL, как мне узнать, какие запросы заняли такую огромную память? Как я могу это проверить? Наш сервер работает на следующих деталях:
OS: Linux 2.6.18
CPU: GenuineIntel, Intel(R)Xeon(R)CPU W3550 @ 3.07GHz
Average Load: 808.18;674.21;587.18
database records: 421,031 with 58 tables
Статистика запросов, которую я могу предоставить из PHPMyAdmin:
select 314 k 11.98 k 66.37%
set option 34 k 1,296.59 7.18%
show fields 19 k 712.00 3.94%
update 16 k 620.61 3.44%
alter table 16 k 610.32 3.38%
change db 15 k 569.08 3.15%
insert 15 k 560.20 3.10%
show variables 11 k 434.01 2.40%
show tables 9,752 371.66 2.06%
begin 7,172 273.33 1.51%
результат выполнения 'top':
top - 15:20:07 up 1 day, 6:13, 1 user, load average: 497.30, 512.17, 542.15
Tasks: 7743 total, 5 running, 7738 sleeping, 0 stopped, 0 zombie
Cpu(s): 23.9%us, 50.9%sy, 0.1%ni, 25.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8173372k total, 8048380k used, 124992k free, 1816952k buffers
Swap: 2096376k total, 216k used, 2096160k free, 533876k cached
Я надеюсь, что кто-то может дать мне несколько советов, поскольку я уже некоторое время сталкиваюсь с этой проблемой, и у меня нет никого, к кому я мог бы попросить совета. Заранее спасибо.
обновление: dmesg
CPU5: Temperature above threshold, cpu clock throttled
CPU7: Temperature/speed normal
CPU2: Temperature/speed normal
CPU6: Temperature/speed normal
CPU1: Temperature above threshold, cpu clock throttled
CPU3: Temperature/speed normal
CPU0: Temperature/speed normal
CPU4: Temperature/speed normal
CPU6: Temperature/speed normal
CPU5: Temperature/speed normal
CPU1: Temperature/speed normal
CPU2: Temperature/speed normal
CPU4: Temperature/speed normal
CPU7: Temperature/speed normal
CPU0: Temperature/speed normal
CPU3: Temperature/speed normal
brute[19592]: segfault at 0000000000000028 rip 00000000080a592f rsp 00000000ffae3a28 error 6
brute[19539]: segfault at 0000000000000028 rip 00000000080a592f rsp 00000000ffae3a28 error 6
CPU2: Temperature/speed normal
CPU4: Temperature/speed normal
CPU7: Temperature/speed normal
CPU1: Temperature/speed normal
CPU5: Temperature/speed normal
CPU3: Temperature/speed normal
CPU6: Temperature/speed normal
CPU0: Temperature/speed normal
CPU0: Temperature/speed normal
CPU7: Temperature/speed normal
CPU6: Temperature/speed normal
CPU1: Temperature/speed normal
CPU2: Temperature/speed normal
CPU3: Temperature/speed normal
CPU5: Temperature/speed normal
CPU4: Temperature/speed normal
brute[21368]: segfault at 0000000000000000 rip 0000000008048f03 rsp 00000000ffb82db0 error 4
ТОП-результат сегодняшнего дня:
top - 10:42:47 up 3 days, 1:35, 1 user, load average: 4.35, 4.53, 4.59
Tasks: 187 total, 5 running, 182 sleeping, 0 stopped, 0 zombie
Cpu(s): 12.7%us, 38.5%sy, 0.0%ni, 48.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8173372k total, 7800156k used, 373216k free, 1653768k buffers
Swap: 2096376k total, 216k used, 2096160k free, 2723732k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27913 consulti 25 0 31096 3700 1172 R 100.2 0.0 1484:40 perl
27916 consulti 25 0 31096 3732 1204 R 100.2 0.0 1051:59 perl
28213 consulti 25 0 31096 3736 1204 R 100.2 0.0 1073:30 perl
28210 consulti 23 0 31096 3740 1204 S 86.9 0.0 1016:23 perl
3205 mysql 15 0 333m 55m 5416 S 13.6 0.7 143:36.73 mysqld
14616 apache 15 0 333m 33m 6056 S 4.7 0.4 1:02.12 httpd
25104 consulti 18 0 31096 3732 1204 R 4.7 0.0 486:12.74 perl
2702 root 15 0 12744 1148 808 R 0.3 0.0 0:00.01 top
1 root 15 0 10352 696 588 S 0.0 0.0 0:01.62 init
2 root RT -5 0 0 0 S 0.0 0.0 0:00.07 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/1
6 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
7 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/1
8 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/2
9 root 34 19 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/2
10 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/2
11 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/3
12 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/3
13 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/3
14 root RT -5 0 0 0 S 0.0 0.0 0:00.05 migration/4
15 root 34 19 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/4
16 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/4
17 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/5
Прежде всего, как и некоторые другие в комментариях, меня очень беспокоит minerd и brute процессы. Небольшая детективная работа Google показывает, что эти имена связаны с майнингом биткойнов и автоматическая генерация сетевого трафика (например, один узел в DDoS-атаке) соответственно, указывая на то, что кто-то другой может использовать ваш сервер в своих целях.
Уберите это с дороги (и, пожалуйста, исправьте это быстро), и вы, вероятно, также сможете улучшить ситуацию с небольшой настройкой базы данных. Учитывая анализ опубликован RandomSeed что у вас, вероятно, есть неиспользуемая оперативная память, и вы вместо этого ожидаете на диске, и примечание о том, что вы добавили оперативную память на сервер без комментариев по поводу каких-либо других изменений, я подозреваю, что ваш буферный пул MySQL слишком мал.
Это сводится к настройке производительности сервера базы данных 101: диски медленные, память - быстрая. Базы данных любят предварительно загружать или буферизовать данные и индексы в памяти, чтобы снизить потребность в использовании более медленного жесткого диска. MySQL имеет несколько параметров конфигурации, которые определяют, сколько данных разрешено кэшировать таким образом. Если вы добавляете память на сервер, но не меняете эти настройки MySQL, это немного поможет, обеспечив достаточное количество оперативной памяти для других (не MySQL) процессов, но это не сильно повлияет на производительность вашей основной базы данных. ; вам также необходимо сообщить MySQL о добавленной вами новой памяти.
Итак, как это сделать? В случае MySQL это немного сложно, потому что MySQL поддерживает несколько механизмов хранения. Вы, вероятно, используете InnoDB, но у вас также может быть MyISAM или даже их сочетание для разных таблиц. К сожалению, не зная, какие таблицы используют какой механизм хранения и (если есть смешение) с какими размерами и объемами запросов, трудно точно посоветовать, как изменить конфигурацию MySQL.
Ваша проблема не связана с ОЗУ (больше нет):
Однако, вероятно, этого не было до того, как вы перешли на 8 ГБ.
Теперь он, вероятно, будет привязан к вводу-выводу, и, вероятно, виноват MySQL:
Наиболее частая причина, по-видимому, запроса с интенсивной загрузкой процессора: долгое время ожидания ввода / вывода (т.е. чтение данных с диска). Такие запросы обычно не имеют индексирования poper и / или извлекают слишком много данных.
Теперь вам нужно определить, что это за запросы. Хорошая отправная точка - мониторинг времени их выполнения.
Из вашего описания думаю, что ваша система подкачивает. Вероятно, вам нужно уменьшить выделение памяти, настроенное в /etc/my.cnf
Вы можете увидеть, какие процессы используют физическую память, запустив:
ps aux --sort=-rss|head -10