Макс Лапшин (levgem) wrote,
Макс Лапшин
levgem

Categories:

Very high load: история одного тюнинга

На сервере у одного клиента, раздаюшего видео, возникла проблема: на 5 гигабитах начинаются провалы трафика. На сервере 6 SSD, два Xeon E5 и 128 GB памяти.


Сразу на сервере запустил htop и увидел, что иногда нагрузка на всех 16 ядрах (два 8-ядерных Xeon E5) взлетает до полных 1600%, при этом красного больше, чем зеленого. Красным индицируется sys load, т.е. загрузка ядра линукса, а зеленым — сам flussonic. Это очень нездоровая ситуация, потому что нормальное соотношение должно быть хотя бы 1:10.

В моменты всплеска нагрузки до 1600% происходит срыв трафика, поэтому было принято предположение,
что надо заняться уменьшением sys части нагрузки, т.е. выяснить, почему линукс потребляет столько CPU.



Достаточно быстро нашел в интернете, что причина может быть в том, что в системе стоит 128 GB памяти, а она организована не в HugeTables, т.е. адресуется страницами по 4 КБ, а не по 2 МБ.
Поскольку на уже загруженном сервере HugeTables никак не включались, пришлось перезагружать сервер с настройкой на аллокацию 50 тыс HugeTables, но особой разницы не возникло


Мне помогал инженер хостера, он предположил, что проблема может быть в том, что сетевая карточка раскидывает прерывания на два процессора, а не на один и из-за этого возникают проблемы. Перезагрузили компьютер, указав в /etc/modules опции для модуля:

ixgbe RSS=8,8

что бы он создал 8, а не 16 очередей, но это не помогло: было создано опять 16 очередей, поэтому скрипт irq_set_affinity.sh раскидал прерывания по всем ядрам.


Поправили скрипт irq_set_affinity.sh, что бы он раскидывал по первым 8 ядрам, которые на 1-м процессоре. Ситуация стала немного лучше, но только пришлось первую и третью очереди перекинуть на другие ядра.


После этого проверили как система работает при регулярном сбросе дисковых кешей:

echo 1 > /proc/sys/vm/drop_caches

CPU упал, но резко вырос disk usage. К сожалению, регулирование настроек VFS никаких наблюдаемых результатов не дало:

vm.vfs_cache_pressure = 1000

В итоге помогло отключение HugeTables с выставлением минимального размера свободной памяти:

sysctl vm.min_free_kbytes=10240000

которое нельзя занимать под кеш.

Итого: минимальный размер памяти под ядро и раскидывание прерываний по первому процессору помогло. Нагрузка выросла с 5 гигабит до 10 гигабит.
Tags: flussonic, highload, эрливидео
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 7 comments