Сервер под нагрузкой поисковиков падает

Гугли параметр vm.swappines, но вообще очень странно, что поисковые боты так нагружают систему.

Load Average вообще зашкаливает.

Включай atop и смотри откуда ноги растут. Может это диск не справляется.

Как ты определил, что в свап уходит?

atop раньше не юзал, поэтому при первом взгляде на него я ничего не понял.

В htop'е посмотрел. Забивается оператива примерно на 14Гб из 24 и дальше опратива стоит на месте, а значение свапа изменяется.

Сделай 10

Ну или iostat/iotop.

Сделал.

А вообще может это не от поисковиков? Загрузка не свербольшая для такого железа. Может в апаче или мускуле что-то неправильно прописано? Какое-то значение...

my.cnf

...
key_buffer_size		= 2048M
max-connect_errors = 50
table_open_cache = 36288
innodb_buffer_pool_size = 2048M
open_files_limit = 18200
...

Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          256
    MaxRequestsPerChild  3000
</IfModule>
...

Вот сейчас например, всё те же боты сканируют и всё ок. А в тот раз, бац и всё, система перегружена.

Какие ещё идеи есть?

Возможно проблема совсем в другом.

По факту забивается RAM до определённого значения и активно юзается свап.

Возможно проблема совсем в другом.

Дисковую нагрузку ты решил не смотреть? Ок.
Кстати, для приличия на фронтенд надо поставить nginx.

Кстати, для приличия на фронтенд надо поставить nginx.

Удваиваю, даже утраиваю этого господина

Есть nginx. Ничего подозрительного я не заметил.

Судя по графикам в munin нагрузка на диск адовая.

Не ведутся ли какие-то логи по нагрузке на диск?

Не ведутся ли какие-то логи по нагрузке на диск?

iotop
iostat

И посмотри уже в atop загрузку cpu и его wait.

А кто-нибудь вообще пробовал тюнить хотья что-то для производительности? Или изначально решили просто поставить железо покруче, а на всё остальное забить?

Как именно веб-сервер устроен? На чём сайт крутится?

Сейчас нагрузки особой нет.

Смотрю iotop, понемногу пишут/читают процессы php и mysql.

iostat:

root@host:~# iostat
Linux 3.2.0-4-amd64 (host.ru) 	28.08.2014 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10,09    0,00    3,96    3,73    0,00   82,23

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
cciss/c0d0      236,36      1602,29       905,56    7745395    4377416

Судя по atop, основная нагрузка на диск от mysql:

rdisk | wrdisk | wcancl | dsk | cmd
3.2G  | 343G   | 340G   | 98% | mysql

А кто-нибудь вообще пробовал тюнить хотья что-то для производительности?

Да, тюнил. апач+нгинкс+мускуль+пхп тюнил.

Как именно веб-сервер устроен? На чём сайт крутится?

ISPmanager. Сайтов много, в основном на джумла.

Железо, если что:

product: ProLiant DL160 G5 ()
product: Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz
slot: Processor 0 Internal L2 Cache
   size: 12MiB
memory size: 24GiB

Диск такой: HDD 450GB 15K SAS DF0450B8054

Одна штука? Даже не RAID-1? Он от одного только random read помрет если куча сайтов да ещё и база данных на нем же.

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

Я не совсем понял рейд там или нет. Вроде как один. Не рейд.

root@host:~# hwinfo --disk
35: None 00.0: 10600 Disk                                       
  [Created at block.243]
  Unique ID: ZJ2m.Fxp0d3BezAE
  Parent ID: x1VA.DXZOmjGcDK6
  SysFS ID: /class/block/cciss!c0d0
  SysFS BusID: c0d0
  SysFS Device Link: /devices/pci0000:00/0000:00:05.0/0000:09:00.0/cciss0/c0d0
  Hardware Class: disk
  Model: "Disk"
  Driver: "cciss"
  Driver Modules: "cciss"
  Device File: /dev/cciss/c0d0
  Device Files: /dev/cciss/c0d0, /dev/disk/by-id/cciss-3600508b1001052395358413343360007, /dev/disk/by-id/wwn-0x600508b1001052395358413343360007, /dev/disk/by-path/pci-0000:09:00.0
  Device Number: block 104:0-104:15
  BIOS id: 0x80
  Geometry (Logical): CHS 107724/255/32
  Size: 879032432 sectors a 512 bytes
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #28 (RAID bus controller)

Неужели из-за небольшого увеличения нагрузки, может так сильно тормозить?

imho в job с такой базовой диагностикой: ни информации по rss, vms по процессам, ни вменяемого описания конфигурации какой-либо подсистемы, ни вообще описание окружения с хотя бы схематическим параметризированием.

man iostat, кстати, тоже почитай, чтоб предоставить iops, а не килобайты в секунду.

Хотя на вскидку итак понятно, что mysql упирается в io, потому что читает и пишет на диск постоянно.

man iostat, кстати, тоже почитай, чтоб предоставить iops, а не килобайты в секунду.

Читал, не нашёл в мане такого.

ни информации по rss, vms по процессам, ни вменяемого описания конфигурации какой-либо подсистемы, ни вообще описание окружения с хотя бы схематическим параметризированием.

Пока нет такого опыта как у Вас, поэтому и спрашиваю.

Внимательно выслушаю любые предложения и постараюсь предоставить все необходимые для диагностики данные.

Давайте представим такое. Ситуация опять повторяется.

Большая нагрузка на диск, система грузит оперативу, LA зашкаливает, система уходит в свап.

Какие должны быть мои действия на момент нагрузки сервера, а не после этой нагрузки?

(Это мне инструкция на будущее)

Спасибо.

До этого, по всей видимости собирал неправильные данные и не смог вовремя посмотреть нужные утилиты.

Что за дистрибутив?

Debian 7.

Если мое предположение про mysql верно, то для начала хотелось бы взглянуть на вывод:

iostat -x 2 6

В целом, в идеальном сетапе чтения с диска быть не должно/должно быть минимальным. Если для организации идеального сетапа памяти не достаточно, то в общем случае поможет поднятие производительности дисковой подсистемы (ssd, raid0), однако на вскидку это видится менее эффективным и более дорогим вариантом. Хотя опять же без представления конкретики окружения (сколько баз, сколько клиентов, каков объем,какой движок базы, что как с чем работает, схема использования nginx, apache, php) всё это весьма для сферического типового случая в вакуме.

Зачем в этой схеме вообще нужен swap — представить себе не могу. Если предположить его гипотетическое использование — значит уже в проектировании что-то пошло не так.

С нуля проектировал не я, приходится админить уже то что есть. В основе лежит панель ISPmanager. Я бы наверное сделал немного по-другому, если б делал сам с нуля.

Предположим, что в аппаратной части расширение невозможно. Допустим, что это действительно мускул грузит дисковую подсистему. Что я должен сделать со своей стороны относительно мускуля? Какие параметры оптимизировать? Я в своё время тюнил его в основном по рекомендациям mysqltuner.pl.

Некоторые директивы из конфига MySQL я привёл несколькими постами выше (полный конфиг тут).

Вывод iostat в обычном, ненагруженном состоянии:

root@host:~# iostat -x 2 6
Linux 3.2.0-4-amd64 (host.ru) 	29.08.2014 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11,31    0,00    3,31    1,72    0,00   83,66

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        1,29    29,81   98,87   21,03  2425,14   582,36    50,17     0,68    5,64    2,51   20,37   1,26  15,08

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10,01    0,00    1,13    0,00    0,00   88,87

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00    29,00    0,00   58,00     0,00  1468,00    50,62     0,00    0,07    0,00    0,07   0,07   0,40

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,31    0,00    0,06    0,06    0,00   99,56

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00    47,00    4,50    3,50    18,00   204,00    55,50     0,03    4,00    7,11    0,00   0,50   0,40

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,06    0,00    0,06    0,00    0,00   99,87

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00    26,50    0,00    8,50     0,00   140,00    32,94     0,00    0,00    0,00    0,00   0,00   0,00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1,81    0,00    0,19    0,00    0,00   98,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00     0,00    0,00    4,00     0,00    30,00    15,00     0,00    0,00    0,00    0,00   0,00   0,00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3,88    0,00    0,13    0,00    0,00   96,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00    26,00    0,00    4,50     0,00   130,00    57,78     0,00    0,44    0,00    0,44   0,44   0,20

Спасибо за помощь.

А какое поделие на этом сервере крутится, что его с такими чудовищными ресурсами нагибает поисковик?

Поделие чего? Конкретнее можно? Сайтов 100-200, в основном на джумле. апач+нгинкс+мускуль+пхп в cgi моде. На базе ISPmanager. Не думаю, что именно поисковик его нагибает, бывает что поисковик шестерит и всё норм, а бывает, как я описал всё выше. Вот я и хочу разобраться, почему оно так случается и что нужно сделать для того, чтобы чтобы такого не повторялось.

Судя по atop, основная нагрузка на диск от mysql

Так везде на среднестатистических xAMP конфигах и бывает зачастую. Большая часть данных то читается и пишется СУБД.

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

Лучше смотри потребление памяти. Поскольку память -> своп -> диск -> запредельный LA.

Что можно сказать об этом конфиге? Есть ли в нём что-то откровенно кривое? Мне кажется это из-за кривой настройки мускуля (настраивал на основе дефолтного конфига и рекомендация mysqltuner и tuning-primer. Незначительные по моему мнению директивы я сюда не пишу.

root@host:/tmp# cat /etc/mysql/my.cnf | grep -v "^#"
key_buffer_size		= 2048M

max_allowed_packet	= 16M
thread_stack		= 192K
thread_cache_size       = 8
max-connect_errors = 50

max_connections = 256

table_cache		= 1024
wait_timeout		= 120
interactive_timeout	= 100
connect_timeout		= 120
query_cache_limit = 16M

query_cache_size        = 128M

join_buffer_size = 8M
read_buffer_size = 2M
sort_buffer_size = 256K

tmp_table_size = 512M
max_heap_table_size = 512M

table_open_cache = 16384

table_definition_cache = 512

innodb_buffer_pool_size = 2048M

open_files_limit = 18200

Насчёт потребления памяти, я уверен, что именно мускуль потребляет больше всего памяти и именно он нагружает систему.

возможно стоит начать с того, что вернуться к дефолтным (не таким завышенным значениям параметров) настройкам в my.cnf и посмотреть как оно будет.

Если уверены что проблема в мускуле - попробуйте запустить MySQL Tuning Primer и посмотреть его рекомендации.
Так же во время «аномальной» нагрузки, не помешает глянуть

mysql> show processlist;

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

Значит во время нагрузки план моих действий таков:

1. Я смотрю atop, скорее всего там будет показана бешеная нагрузка от mysql

2. Я смотрю show processlist;

3. ??? Что я должен делать дальше? Отключать сайт на который идёт нагрузка , через ISPmanager? Или останавливать процессы MySQL?

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

Действительно ли может быть такой треш всего лишь от одного запроса? Или скорее всего их несколько?

маловероятно, но возможно...

всего лишь от одного запроса

может

Сайтов 100-200, в основном на джумле

их брутфорсят. инфа 99%. смотри apache server-status

Бруты я отсеиваю самопальным скриптом.

В выявлении плохой базы помог мониторинг processlist'а и утилита mk-query-digest.

Спасибо за помощь всем.