Я сталкивался с PostgreSQL с большими БД, фрагментацию памяти можно увидеть несколькими способами:
1. Самый простой это htop с показом тредов ядра, всегда в топе будет висеть kswapd{0,1} и большой systime
2. perf top, isolate_freepages_block, будет в топе висеть.
Вот тут хорошо эта ситуация описана: habr.com/ru/company/odnoklassniki/blog/266005
vm.swappiness это софт порог, если памяти не хватает, например в следствии фрагментации, то все равно будет swap. Вариант крутить min_free_kbytes и отключить swap вообще, как бы если БД туда пошла это все равно уже могила, вывод не правильно отсайзили сервер.
Для PostgreSQL лучше использовать Huge Pages, так как большие страницы не подвержены фрагментации, поэтому под нужды PostgreSQL (при правильном сайзинге) всегда будет память.
И да тут в статье не написано, но желательно HugePages запереть под процесс через vm.hugetlb_shm_group = GID (PostgreSQL) и будет счастье. И отрубить Transparent Huge Pages это зло
(https://habr.com/ru/company/tinkoff/blog/446342/). Для БД например IBM, RedHat рекомендует отключать.
А вот что может еще немного ускорить БД: увеличение kernel.sched_migration_cost_ns = 500000 -> kernel.sched_migration_cost_ns = 5000000 (на порядок)
Хорошо про это рассказывал Илья Космодемьянский из Data Egret на HiLoad. Если вкратце, то время работы процесса на 1 ядре будет увеличено до миграции на другое или сна, тем самым вероятность выполнения 1 транзакции за проход увеличивается.
И следите за NUMA зонами, пример, 1 физ сервер с 2 сокетами. Память делиться на 2 NUMA зоны. Одна ближе к 1 сокету, 2-ая зона ко второму. Если вы аллоцируете память под shared_buffers больше чем 1 зона NUMA, то при заполнении 1 зоны память из второй не будет использоваться, а процессы пойдут в swap. Поэтому если ожидается такой кейс, необходимо использовать NUMA interleaving (править стартовые скрипты, добавляя numactl --interleave=all перед стартом процесса PostgreSQL)
Может я что то упустил, но почему приложения сразу не пишут по сети свои логи в какое то место, будь то Graylog, Kafka?
И вопрос по Graylog, почему складывается? На прошлой работе был кейс: 5 серверов Graylog и 6 ElasticSearch (2 мастера без хранения), все это VM. Глотали 350k json в сек в пике и норм.
Да и к проблеме безопасности Kibana, недавно вышел форк от Амазона, где есть рабочий и бесплатный аналог Shield тык: opendistro.github.io/for-elasticsearch
Это хорошо подходит для небольших БД, так как сливать раз в сутки бэкап БД размером в 15-20 ТБ уже так не выйдет. С свое время реализовывал бэкап больших БД через снапшоты на хранилках
Появление swap'a на проде говорит о нескольких вещах:
1. Кто то не умеет сайзить сервера, увы не все понимают и умееют
2. Течет память в приложении
3. Архитектурная ошибка (вопрос об автоскейлинге), лучше в пике нагрузке добавлять серверов, чем иметь тормоза swap, так как конечному клиенту пофигу что на вас сервис пришло сразу 1000 клиентов, есть SLA и надо его держать.
50% пойдет на нужны самой ОС и страничного кеша ядра, особенно при использовании типа хранения индекса mmapfs. Всегда следите за фрагментацией памяти, особенно где большой интенсивный IO по диску. Симптомы фрагментации (большой systime по процессору, так как вызывается интенсивной работой kswapd0(1), потоком ядра. Например в htop'e можно поставить отображать процессы ядра, он будет всегда в топе по CPU. Второе смотреть через perf top isolate_freepages_block в топе) Хорошая статья у одноклассников habr.com/company/odnoklassniki/blog/266005 в помощь.
Регулировать можно через sysctl параметром vm.min_free_kbytes (отправная точно 1% от общей оперативной памяти), нужно понимать, что эта память всегда будет свободна.
Не разу таких ситуаций не было с G1GC.
У меня есть один ES 2.x работает на 8 Java (оракловая jdk-8u172-linux-x64.rpm)
Никаких проблем. А вы не пробовали через jstatd посмотреть, что происходит в Heap.
Собрать логи GC, проанализировать их в gceasy.io, очень хорошо показывает проблемы. Вопрос номер два, не наблюдался большой systime, что может быть указателем на большую фрагментацию памяти.
По поводу компрессии курсоров, проще в настройка Java выставить -XX:+UseCompressedOops, она просто не даст запуститься с объемом Heap когда компрессия отключается (будет ругаться).
Дополнительно перфоманса можно выжать, если Java покрутить)
Я на проде использую GC G1, Huge Pages (-XX:+UseLargePages) большие странички не свопятся, не подвержены фрагментации и все остальные плюхи.
Желательно писать логи GC во время подручивания Java и анализировать их например через , чтоб оценить работу GC
А так же, использовать jstatd и VusialVM для просмотра работы GC в режиме online.
В ранних версия эластика и Java задавался объем young поколения (обычно 1 GB) через параметр -Xmn
Столкнулся с таким кейсом, когда очень активно использовался young space эластиком, и так как объем был небольшой частый вызов GC. Увеличил в несколько раз наблюдая через VisualVM. Итог нет бешеного GC, эластик стал работать существенно быстрее.
Для тех, кто юзает mmapfs через sysctl покрутить надо vm.min_free_kbytes для более раннего запуска дефрагментации памяти.
Mb: asus rog strix b450, cpu: amd 2600x, gpu: Radeon 5700xt red devil от powercolor, ubuntu 18.04 полет отличный, без всяких проблем.
1. Самый простой это htop с показом тредов ядра, всегда в топе будет висеть kswapd{0,1} и большой systime
2. perf top, isolate_freepages_block, будет в топе висеть.
Вот тут хорошо эта ситуация описана: habr.com/ru/company/odnoklassniki/blog/266005
vm.swappiness это софт порог, если памяти не хватает, например в следствии фрагментации, то все равно будет swap. Вариант крутить min_free_kbytes и отключить swap вообще, как бы если БД туда пошла это все равно уже могила, вывод не правильно отсайзили сервер.
Для PostgreSQL лучше использовать Huge Pages, так как большие страницы не подвержены фрагментации, поэтому под нужды PostgreSQL (при правильном сайзинге) всегда будет память.
И да тут в статье не написано, но желательно HugePages запереть под процесс через vm.hugetlb_shm_group = GID (PostgreSQL) и будет счастье. И отрубить Transparent Huge Pages это зло
(https://habr.com/ru/company/tinkoff/blog/446342/). Для БД например IBM, RedHat рекомендует отключать.
А вот что может еще немного ускорить БД: увеличение kernel.sched_migration_cost_ns = 500000 -> kernel.sched_migration_cost_ns = 5000000 (на порядок)
Хорошо про это рассказывал Илья Космодемьянский из Data Egret на HiLoad. Если вкратце, то время работы процесса на 1 ядре будет увеличено до миграции на другое или сна, тем самым вероятность выполнения 1 транзакции за проход увеличивается.
И следите за NUMA зонами, пример, 1 физ сервер с 2 сокетами. Память делиться на 2 NUMA зоны. Одна ближе к 1 сокету, 2-ая зона ко второму. Если вы аллоцируете память под shared_buffers больше чем 1 зона NUMA, то при заполнении 1 зоны память из второй не будет использоваться, а процессы пойдут в swap. Поэтому если ожидается такой кейс, необходимо использовать NUMA interleaving (править стартовые скрипты, добавляя numactl --interleave=all перед стартом процесса PostgreSQL)
И вопрос по Graylog, почему складывается? На прошлой работе был кейс: 5 серверов Graylog и 6 ElasticSearch (2 мастера без хранения), все это VM. Глотали 350k json в сек в пике и норм.
Да и к проблеме безопасности Kibana, недавно вышел форк от Амазона, где есть рабочий и бесплатный аналог Shield тык: opendistro.github.io/for-elasticsearch
Угумс, только не Сири, а Алиса
1. Кто то не умеет сайзить сервера, увы не все понимают и умееют
2. Течет память в приложении
3. Архитектурная ошибка (вопрос об автоскейлинге), лучше в пике нагрузке добавлять серверов, чем иметь тормоза swap, так как конечному клиенту пофигу что на вас сервис пришло сразу 1000 клиентов, есть SLA и надо его держать.
Регулировать можно через sysctl параметром vm.min_free_kbytes (отправная точно 1% от общей оперативной памяти), нужно понимать, что эта память всегда будет свободна.
У меня есть один ES 2.x работает на 8 Java (оракловая jdk-8u172-linux-x64.rpm)
Никаких проблем. А вы не пробовали через jstatd посмотреть, что происходит в Heap.
Собрать логи GC, проанализировать их в gceasy.io, очень хорошо показывает проблемы. Вопрос номер два, не наблюдался большой systime, что может быть указателем на большую фрагментацию памяти.
Дополнительно перфоманса можно выжать, если Java покрутить)
Я на проде использую GC G1, Huge Pages (-XX:+UseLargePages) большие странички не свопятся, не подвержены фрагментации и все остальные плюхи.
Желательно писать логи GC во время подручивания Java и анализировать их например через , чтоб оценить работу GC
А так же, использовать jstatd и VusialVM для просмотра работы GC в режиме online.
В ранних версия эластика и Java задавался объем young поколения (обычно 1 GB) через параметр -Xmn
Столкнулся с таким кейсом, когда очень активно использовался young space эластиком, и так как объем был небольшой частый вызов GC. Увеличил в несколько раз наблюдая через VisualVM. Итог нет бешеного GC, эластик стал работать существенно быстрее.
Для тех, кто юзает mmapfs через sysctl покрутить надо vm.min_free_kbytes для более раннего запуска дефрагментации памяти.