Тюним память и сетевой стек в Linux: история перевода высоконагруженных серверов на свежий дистрибутив/Д.Самсонов (Однокласники)
Download as PPTX, PDF0 likes2,059 views
Документ обсуждает оптимизацию памяти и сетевого стека в Linux, основанную на опыте перевода высоконагруженных серверов на новый дистрибутив. Основное внимание уделяется проблемам управления памятью, сетевым распределением и нагрузкой на процессоры, а также способам их решения. Предложены различные методы настройки параметров системы для повышения производительности и уменьшения фрагментации памяти.
Тюним память и сетевой стек в Linux: история перевода высоконагруженных серверов на свежий дистрибутив/Д.Самсонов (Однокласники)
- 1. Тюним память и сетевой стек в Linux: история перевода высоконагруженных серверов на свежий дистрибутив Дмитрий Самсонов
- 2. OpenSuSE 10.2 Release: 07.12.2006 End of life: 30.11.2008 CentOS 7 Release: 07.07.2014 End of life: 30.06.2024
- 3. Видео раздача 4 x 10 Гбит к пользователям 2 x 10 Гбит к хранилищу 256 Гбайт RAM — кэш в памяти 22 х 480 Гбайт SSD — кэша на SSD 2 х E5-2690 v2
- 4. Содержание ● Память ○ OOM killer ○ Swap ● Сеть ○ Broken pipe ○ Распределение сетевой нагрузки по ядрам ○ SoftIRQ
- 6. NODE 0 (CPU N0) 1. Вся физическая память NODE 1 (CPU N1) ZONE_DMA (0- 16MB) ZONE_DMA32 (0- 4GB) ZONE_NORMAL (4+GB) 2. NODE 0 3. Каждая зона 20*PAGE_SIZE 21*PAGE_SIZE 22*PAGE_SIZE 23*PAGE_SIZE 24*PAGE_SIZE 25*PAGE_SIZE 26*PAGE_SIZE 27*PAGE_SIZE ... 28*PAGE_SIZE ... 29*PAGE_SIZE ... 210*PAGE_SIZE ...
- 7. Что происходит? OOM killer, скачки system CPU!
- 8. Фрагментация памяти Память после загрузки сервера Через некоторое время Ещё через какое-то время
- 9. Почему это происходит? Мало свободной памяти Memory pressure
- 10. Что делать с фрагментацией? Увеличивать vm.min_free_kbytes! High/low/min watermark. /proc/zoneinfo Node 0, zone Normal pages free 2020543 min 1297238 low 1621547 high 1945857
- 11. Информация о текущей фрагментации /proc/buddyinfo Node 0, zone DMA 0 0 1 0 ... Node 0, zone DMA32 1147 980 813 450 ... Node 0, zone Normal 55014 15311 1173 120 ... Node 1, zone Normal 70581 15309 2604 200 ... ... 2 1 1 0 1 1 3 ... 386 115 32 14 2 3 5 ... 5 0 0 0 0 0 0 ... 32 0 0 0 0 0 0
- 12. Почему это плохо повышать min_free_kbytes? Потому что часть памяти размером с min_free_kbytes не может быть использована
- 13. Память Swap
- 14. Swap при 40GB свободной памяти и vm.swappiness=0! Что происходит?
- 15. NODE 0 (CPU N0) 1. Вся физическая память NODE 1 (CPU N1) ZONE_DMA (0- 16MB) ZONE_DMA32 (0- 4GB) ZONE_NORMAL (4+GB) 2. NODE 0 3. Каждая зона 20*PAGE_SIZE 21*PAGE_SIZE 22*PAGE_SIZE 23*PAGE_SIZE 24*PAGE_SIZE 25*PAGE_SIZE 26*PAGE_SIZE 27*PAGE_SIZE ... 28*PAGE_SIZE ... 29*PAGE_SIZE ... 210*PAGE_SIZE ...
- 16. Неравномерное использование памяти между нодами NODE 0 (CPU N0) NODE 1 (CPU N1) Free Used Free Used
- 17. numastat -m <PID> numastat -m Node 0 Node 1 Total --------------- --------------- --------------- MemFree 51707.00 23323.77 75030.77 ... Текущее распределение по нодам
- 18. Что делать с NUMA? Выключить NUMA Целиком для ядра: numa=off Для процесса: numactl — interleave=all <cmd> Оптимизировать приложение Многопоточность во всём Node affinity
- 19. Сеть
- 20. Что уже должно быть сделано Ring buffer: ethtool -g/-G Transmit queue length: ip link/ip link set <DEV> txqueuelen <PACKETS> Receive queue length: net.core.netdev_max_backlog Socket buffer: net.core.<rmem_default|rmem_max> net.core.<wmem_default|wmem_max> net.ipv4.<tcp_rmem|udp_rmem> net.ipv4.<tcp_wmem|udp_wmem> net.ipv4.udp_mem Offload: ethtool -k/-K
- 21. Сеть Broken pipe
- 22. Фон ошибок broken pipe. В tcpdump - half-duplex close sequence. Что происходит?
- 23. OOO Out-of-order пакет, т.е. пакет неправильной очерёдности (с неправильным номером SEQ).
- 24. Что делать с OOO? Отсылать пакеты одного соединения по одному маршруту: Одно процессорное ядро Одна сетевая карта Одна очередь Для этого: Привязывать триды/процессы к ядрам Привязывать очереди сетевой карты к ядрам Использовать RFS
- 25. Было/стало Количество broken pipe/s на сервер
- 26. Чем плохо строгое определение “маршрутов”? Нагрузка на ядра процессора может быть не равномерной
- 27. Сеть Распределение сетевой нагрузки по ядрам
- 29. CPU0 загружен на 100%
- 30. Почему это происходит? 1. Одна очередь - включить больше: ethtool -l/-L 2. Не распределены прерывания: ○ распределить динамически - запустить irqbalance/irqd/birq ○ распределить статически - настроить RSS
- 31. RSS CPU RSS Network eth0 Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7 0 1 2 3 4 5 6 7 8 9 10 11 12
- 32. CPU0 - CPU7 загружен на 100%
- 33. Половина ядер загружены на 100%
- 35. 16 ядер загружены на 100%
- 36. scaling.txt RPS = Software RSS XPS = RPS для исходящих пакетов RFS? Учитывает номер ядра потребителя. https://www.kernel.org/doc/Documen tation/networking/scaling.txt
- 37. Почему RPS/RFS/XPS это плохо? 1. Нагрузка на ядра процессора может быть не равномерной. 2. Оверхед по CPU
- 38. Accelerated RFS Есть у Mellanox, но после включения скорость не поднималась выше 5Gbit/s на 10G интерфейсах.
- 39. Intel Signature Filter (он же ATR - Application Targeted Receive) - аналог RPS+RFS.
- 40. Сеть SoftIRQ
- 42. Откуда берутся SoftIRQ Network eth0 Q0 Q... CPU C0 C... HW IRQ 42 RSS
- 43. Откуда берутся SoftIRQ Network eth0 Q0 Q... CPU C0 C... HW IRQ 42 SoftIRQ NET_RX CPU0 RSS Обработка HW interrupt завершена
- 44. Откуда берутся SoftIRQ Network eth0 Q0 Q... CPU C0 C... HW IRQ 42 SoftIRQ NET_RX CPU0 RSS NAPI poll Обработка HW interrupt завершена
- 45. Что делать с высоким SoftIRQ?
- 47. Чем плоха модерация прерываний? Надо выбирать между пропускной способностью и latency
- 50. Спасибо за внимание! ● Блог Одноклассников на Хабре http://habrahabr.ru/company/odnoklassniki/ ● Тестирование аварий / Андрей Губа завтра, 3 зал, 17:30 http://www.highload.ru/2015/abstracts/1913.html Дмитрий Самсонов [email protected]
Editor's Notes
- #2: Привет, админы и сочувствующие! Всегда приятно оказаться среди такого количества единомышленников. Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в социальной сети Одноклассники.
- #3: В конце прошлого года мы начали переводить наши сервера со старого Opensuse на новый Centos, потому что обновлять пакеты своими силами становилось всё труднее, разработчики требовали новые версии приложений и библиотек, а безопасники пугали уязвимостями.
- #4: Благодаря качественному подготовительному процессу миграция пошла гладко и центос пополз по проду, пришла очередь серверов видео раздачи, самых мощных и нагруженным в проде таких серверов у нас больше 40 после раскатки мы столкнулись с чередой проблем, так же заодно мы решили разобраться и с некоторыми старыми проблемами
- #5: о том как мы их решали и заново открывали для себя линукс и будет мой доклад Всего будет 5 частей - 2 про память и 3 про сеть. Итак, начнём.
- #7: Ноды Зоны Чанки память доступна приложениям не как 1 кусок, а как много кусков разного размера сначала они большие, по мере выделения приложениям они режутся на более мелкие
- #8: 18:00 до 12:00 час пик, ночь
- #9: Фрагмантация есть всегда, но не всегда она мешает.
- #10: Memory pressure - интенсивное использование памят мы столкнулись с memory pressure
- #11: увеличивая шанс, что в ней будут свободными страницы нужного размера уровень (watermark) при котором начинается reclaim и в случае неудачи compaction (дефрагментация памяти) увеличивать пока проблемы не прекратятся, у нас 1Г, а по умолчанию высчитывает ядро по объёму памяти
- #13: ни приложение, ни ядром даже под page cache Был случай, когда спасло только min_free_kbytes =10Г
- #15: Кроме фрагментации. Может просто тормозить, или опять же съедать system time, т.к. свободные страницы будут на другой ноде. NUMA
- #16: если хв и ос Numa-aware, то приложения будут получать память на той ноде на которой работают, будет выше cache hit и выше скорость
- #17: у нас на серверах есть 1 большой tmpfs, который создаётс 1 тридом, поэтому в основном использовалась память одной ноды при высоком memory pressure ядро может решить, что засвопить часть страниц лучше, чем мигрировать их между нодами
- #18: у нас на серверах есть 1 большой tmpfs, который создаётс 1 тридом, поэтому в основном использовалась память одной ноды
- #19: Многопоточность, что бы не было какого-то элемента приложения, который будет висеть на одной ноде и пороть работу всего приложегния.
- #20: Про сеть с высокой пропускной способностью!
- #23: Проблема была ДО centos Первая сетевая проблема заключалась в фоне ошибок broken pipe. По дампу трафика было видно, что клиенты, связь с которыми завершается ошибкой Broken pipe, пред этим совершают быстрое закрытие TCP соединения - half-duplex close sequence. Почему это происходит?
- #24: Приводит к некорректному (для отправителя данных) закрытию соединения - half-duplex tcp close sequence, т.е. отправитель просто получит RST. OOO, т.е. не тот SEQ. это плохо, потому что retransmit
- #25: выбор очередей в карте выбор интерфейсов в бонде (в обоих направлениях) выбор ядра для очереди выбор ядра для процесса/триды про RFS будет дальше
- #26: результат
- #28: Поиск в гугле по повышенной нагрузке на CPU0 возвращает от 50 тысяч до 150 тысяч страниц. Как вы думаете сколько по CPU1? До миллиона, но ни одного релевантного.
- #31: динамика распределяет неравномерно строго говоря, динамическое распределение может быть полезным, когда важна latency, т.к. демоны учитывают NUMA и соблюдают локальность данных
- #32: Допустим мы это сделали CPU0 отпустило Пропускная способность выросла, но вскоре опять упёрлись в нагрузку по другим ядрам
- #33: статическое распределение через RSS
- #34: так МОЖЕТ выглядеть динамическое распределение через демоны как видно нагрузка по прежнему не равномерна
- #36: RSS может распределить нагрузку только на 16 очередей
- #37: мы это используем!
- #38: т.к. отдельные соединения могут быть быстрее если тридов приложеня меньше, чем ядер
- #40: Хуже распределяет нагрузку и допускает packet reordering
- #41: мутная тема Не смотря на то что это раздача и исходящих пакетов больше, softirq net_rx прерываний значительно больше, об этом поговорим чуть позже.
- #42: Что происходит при получении пакета: …
- #43: генерируются на первый пакет,
- #44: затем отключаются, выгребается N пакетов, затем включаются
- #45: HW отключаются, выгребается N пакетов, затем включаются
- #50: обязательно откатывайте те изменения, который вам не дали однозначного выигрыша! в противном случае рано или поздно они ухудшат производительность системы!
- #51: На выполнение этой задачи было потрачено много времени, но мы решили и старые, и новые проблемы освоили новые технологии и углубили знания о линуксе и самое главное - получили бесценный опыт Подходите ко мне после доклада, задавайте вопросы, рассказывайте про ваши истории успеха и проблемы - мне это интересно!