дак вот как так: https://t.me/devops_ru/422290

А вот так. Все забагованое, насколько я понял. Просто одно у одних работает лучше а у других хуже. Мьі с DM на overlay2 переехали так как в мапере есть баг по забиванию места временньіми файлами, если имадж слишком большой

Он там скачивает, крешится, качает заново и так пока не займет все место на диске

Юзай оверлэй2. Но на дебиане с докером 17.03 с предпоследним ядром не чихает

Ну вот и у меня такое же ощущение. Потому что на 18* у меня проблемы. Попробую на 17 еще, да. Просто у меня пока вопрос - в чём проблемы - в приложении или докере.

Вернусь, как будут какие-то годные результаты.

Еще я сходу спрошу - какое значение backlog используете для нагруженных сервисов ? 1024 не хватает, 10к - вешает приложение. (это всё сырое - тесты еще делаю, это не быстро)

Еще я сходу спрошу - какое значение backlog используете для нагруженных сервисов ? 1024 не хватает, 10к - вешает приложение. (это всё сырое - тесты еще делаю, это не быстро)

хер знает

Деплоил давно и неправда

просто ансиблом катается фикс

В автомате

К слову про предыдущий тред про файловые системы. В ru_доккере тут обратили внимание на то, что есть драйвера на btrfs и zfs, но там чот какие-то предупреждения, что не стоит в продакшн использовать. Я пока с ext4 + overlay2. А кто-то тестировал ? В проде держал тот же btrfs ?

Overlay2 норм, в любом случае - что ты там держать собрался? Стейтфул лучше выносить, а то что остаётся - пофиг. Хотя в проде держал и базы локально, так как они в реплике

Overlay2 норм, в любом случае - что ты там держать собрался? Стейтфул лучше выносить, а то что остаётся - пофиг. Хотя в проде держал и базы локально, так как они в реплике

Ну смутила меня дока докера, что якобы сначала посмотрите на brtfs/zfs, а потом на overlay2. Ну и без EE-редакции btrfs не берите. Сейчас меня больше опыт по размеру backlog для приложения беспокоит.

А какой-то драйвер используется? Storage plugin?

Или просто docker run?

К слову про предыдущий тред про файловые системы. В ru_доккере тут обратили внимание на то, что есть драйвера на btrfs и zfs, но там чот какие-то предупреждения, что не стоит в продакшн использовать. Я пока с ext4 + overlay2. А кто-то тестировал ? В проде держал тот же btrfs ?

С моей подачи. ZFS использовать рекомендую но тем кто знает как с ней работать, а кто не знает начинайте.

Кстати. А родной гластер драйвер вообще существует? И есть ли смысл запариваться?

А какой-то драйвер используется? Storage plugin?

да, обычно драйвер указывается в конфиге докера. А дальше - docker run, etc Кастомы не предполагаются

Кстати. А родной гластер драйвер вообще существует? И есть ли смысл запариваться?

в ранчере точно есть в кубере, думаю, тоже.

в ранчере точно есть в кубере, думаю, тоже.

Мне на swarm засадить бы его

С моей подачи. ZFS использовать рекомендую но тем кто знает как с ней работать, а кто не знает начинайте.

А можно раскрыть это "знают как работать" ?

А можно раскрыть это "знают как работать" ?

Наверное имелось в виду необходимость ECC памяти итд

Кстати. А родной гластер драйвер вообще существует? И есть ли смысл запариваться?

На сайте же есть список, у rexray широкий список

Кстати. А родной гластер драйвер вообще существует? И есть ли смысл запариваться?

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

да, обычно драйвер указывается в конфиге докера. А дальше - docker run, etc Кастомы не предполагаются

Я про storage plugin для контейнера (docker volume create -d local)

А можно раскрыть это "знают как работать" ?

Вопше незнаю как без zfs жить, всюда использую.

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

Мне все на примитивном уровне надо, типа синхронизация файлов Wordpress по разным нодам когда s3 не участвует

Мне все на примитивном уровне надо, типа синхронизация файлов Wordpress по разным нодам когда s3 не участвует

Это пока. Для разминки

Наверное имелось в виду необходимость ECC памяти итд

Нет необходимости в ECC, но если больше 64gb ram будете использовать то желательно.

Нет необходимости в ECC, но если больше 64gb ram будете использовать то желательно.

Как нет? А если память битая, что на диск пойдёт?

Я про storage plugin для контейнера (docker volume create -d local)

Мне для понимания - зачем разным контейнерам разные storage-driver, кроме случаев, когда мы хотим persistance volume, nfs/s3/иное.

Мне все на примитивном уровне надо, типа синхронизация файлов Wordpress по разным нодам когда s3 не участвует

Зеркалирование?

Зеркалирование?

Чего?

Вопше незнаю как без zfs жить, всюда использую.

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

Зеркалирование?

На оба зеркала запишется битая хня

Мне для понимания - зачем разным контейнерам разные storage-driver, кроме случаев, когда мы хотим persistance volume, nfs/s3/иное.

У разных контейнеров разные требования?)

Мне для понимания - зачем разным контейнерам разные storage-driver, кроме случаев, когда мы хотим persistance volume, nfs/s3/иное.

Скорость/цена - извечный вопрос.

На оба зеркала запишется битая хня

Может я не понимаю чего..

Как нет? А если память битая, что на диск пойдёт?

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

Чего?

Дание зеркало или розделени по нодам?

http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

Это разве уже не актуально

У разных контейнеров разные требования?)

+ @AutomationD В том и вопрос - один вопрос, когда для контейнера хотим "сетевую ФС", для persistance - разные storage-драйвера понятны. А на локалхосте зачем ? Просто предлагаю разделить локальные ФС от сетевых ФС.

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

Не в крутости дело а простоте. А какая файловая нам даст такой же инструментарий?

Не в крутости дело а простоте. А какая файловая нам даст такой же инструментарий?

Я в zfs не силён. Что даёт ? Порекламируйте ?

+ @AutomationD В том и вопрос - один вопрос, когда для контейнера хотим "сетевую ФС", для persistance - разные storage-драйвера понятны. А на локалхосте зачем ? Просто предлагаю разделить локальные ФС от сетевых ФС.

Странное предложение

http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

А это не относится ко всем ФС? Если в побьются данные в странице dirty cache, которая должна упасть на ext4, будет что-то принципиально другое?

Странное предложение

Хм, имхо. в треде смешались разные концепции, поэтому и пошло предложение разделить локалхост от сетевых ФС. Чтобы не тратить время, можем в привате определиться в терминах.

Я в zfs не силён. Что даёт ? Порекламируйте ?

Дает пить пиво, мне удевительно слишать подобное. Copy on write, snapshots, commpress, dedup, и многое другое.

А это не относится ко всем ФС? Если в побьются данные в странице dirty cache, которая должна упасть на ext4, будет что-то принципиально другое?

Относится, zfs не сильно подаержена етому.

Хм, имхо. в треде смешались разные концепции, поэтому и пошло предложение разделить локалхост от сетевых ФС. Чтобы не тратить время, можем в привате определиться в терминах.

Ты про фс для локального драйвера, а я в общем - локальный особо не юзаю, поэтому оптимизацией не парился.

Там образы и временные данные от стейтлесс, пох на них

Ты про фс для локального драйвера, а я в общем - локальный особо не юзаю, поэтому оптимизацией не парился.

ээ, дык текущий тред про zfs - это вроде как про локальные ФС. Удалённые ФС - другая история. Или я что-то там пропустил ?)

Дает пить пиво, мне удевительно слишать подобное. Copy on write, snapshots, commpress, dedup, и многое другое.

Пиво в питере есть. А нагрузка на zfs есть ?

Не пропустил, но не понял меня) что ты там хранишь то?

Пиво в питере есть. А нагрузка на zfs есть ?

Если нагрузить то есть, или оверхед имееться ввиду?

Не пропустил, но не понял меня) что ты там хранишь то?

нихрена я там не храню. но в iowait диск уходит. Скорее всего логи в докере, которые на диск льются, но прям на 100% не готов утвердать. Обычные hdd, да

Вернее sas, но разницы там ..

Хм, явно не в фс и докере проблема. Я даже постгри держал ext4+overlay2 и всё это в ceph

Никаких проблем с io

Еще я сходу спрошу - какое значение backlog используете для нагруженных сервисов ? 1024 не хватает, 10к - вешает приложение. (это всё сырое - тесты еще делаю, это не быстро)

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

ERROR: S client not available

А что за логи? Контейнеры генерят? Этож сколько нужно, чтобы диск ложить

А что за логи? Контейнеры генерят? Этож сколько нужно, чтобы диск ложить

Выглядит как дебаг on в проде

Ща опишу.

Выглядит как дебаг on в проде

Он не может быть больше чем журнал у постгри

Еще я сходу спрошу - какое значение backlog используете для нагруженных сервисов ? 1024 не хватает, 10к - вешает приложение. (это всё сырое - тесты еще делаю, это не быстро)

Не только беклог важен, еще надо изменить другие параметри стека.

Смотрите. У меня знатное подозрение, что я где-то не вижу чего-то очевидного. Я пытаюсь грузить приложение по вебсокетам. Прямо сейчас у меня 8(!) клиентов, которые параллельно грузят python-sanic приложение, которое в свою очередь стучится к базам(psql, redis, elastic) и приложению на nodejs. Я вижу загрузку на iowait + si, но не критичную - < 10% в сумме. Всё в докере, я сейчас проверяю, что дело не в нём. История такая - если у меня мало в backlog - я вижу, что начинают отправляться syncookies Если я выкручиваю локальный backlog приложения - примерно через 2 часа приложение перестаёт принимать соединения. Пока я не смог через отладчики получить понятной информации - что именно там происходит.

Не только беклог важен, еще надо изменить другие параметри стека.

если мы про sysctl/ulimit - вроде там накручено достаточно для обработки запросов.

если мы про sysctl/ulimit - вроде там накручено достаточно для обработки запросов.

Не о них.

А что за логи? Контейнеры генерят? Этож сколько нужно, чтобы диск ложить

Логи - обычные логи контейнера: req_start db_conn start de_end ext_req_start итп

если мы про sysctl/ulimit - вроде там накручено достаточно для обработки запросов.

Будет завтра время отпишу. Но не в беклоге проблема ибо без проблем можно держать 500к одновременних конектов а если потюнить то и 1М

Смотрите. У меня знатное подозрение, что я где-то не вижу чего-то очевидного. Я пытаюсь грузить приложение по вебсокетам. Прямо сейчас у меня 8(!) клиентов, которые параллельно грузят python-sanic приложение, которое в свою очередь стучится к базам(psql, redis, elastic) и приложению на nodejs. Я вижу загрузку на iowait + si, но не критичную - < 10% в сумме. Всё в докере, я сейчас проверяю, что дело не в нём. История такая - если у меня мало в backlog - я вижу, что начинают отправляться syncookies Если я выкручиваю локальный backlog приложения - примерно через 2 часа приложение перестаёт принимать соединения. Пока я не смог через отладчики получить понятной информации - что именно там происходит.

syncookies высылаются при заполнении syn queue, а backlog — это accept queue. вам другое крутить надо.

@BaZZiliO попробуйте увеличить net.ipv4.tcp_max_syn_backlog

syncookies высылаются при заполнении syn queue, а backlog — это accept queue. вам другое крутить надо.

Проблема с backlog в том, что при увеличении параметра - приложение просто намертво зависает. Буду рад услышать идеи для тестирования - что именно проверить. Пока из схемы ubuntu -> docker -> alpine -> python Убираю лишние сущности и тестирую на физическом сервере без докеров. точных результатов еще нет, но зависает. Перепроверяю.

Будет завтра время отпишу. Но не в беклоге проблема ибо без проблем можно держать 500к одновременних конектов а если потюнить то и 1М

Проблема может быть не в системе, а в фреймворке или где-то еще. На hello_world приложении проблем не нашёл. Ищу. Пока безуспешно.

Проблема с backlog в том, что при увеличении параметра - приложение просто намертво зависает. Буду рад услышать идеи для тестирования - что именно проверить. Пока из схемы ubuntu -> docker -> alpine -> python Убираю лишние сущности и тестирую на физическом сервере без докеров. точных результатов еще нет, но зависает. Перепроверяю.

Для начала стоит убедиться в том, что крутить backlog вообще надо. У вас accept queue переполняется тоже или только syn queue?

Для начала стоит убедиться в том, что крутить backlog вообще надо. У вас accept queue переполняется тоже или только syn queue?

Сейчас не готов. Завтра или в понедельник отвечу. Спасибо за вопрос. По идее в случае websocket переполняется backlog, но с текущий тестированием - это вопрос. Поставлю мониторинг. Когда я про backlog говорю - чем больше значение backlog в listen, которое я задаю python/nodejs приложениям, тем быстрее они перестают отвечать на запросы. Всё это в тестах сейчас, чтобы не соврать.

Стоп, accept очередь на 8 клиентах у меня точно переполниться не могла. оно там асинхронное всё, конечно, но нет.

Стоп, accept очередь на 8 клиентах у меня точно переполниться не могла. оно там асинхронное всё, конечно, но нет.

ну тогда зря крутили размер accept очереди. но, если есть сомнения, замониторьте.

ну тогда зря крутили размер accept очереди. но, если есть сомнения, замониторьте.

Формально нет - это ж докер: * Клиент * 8 соединений(непрерывно) * Сервер - 8 соединений + 3 базы + docker-сервис * docker-сервис + база А ожидается не 8 соединений, а 50к websocket (с задержкой запросов по 1с)

Исправил слова - внешний сервис => отдельный docker-сервис.

Формально нет - это ж докер: * Клиент * 8 соединений(непрерывно) * Сервер - 8 соединений + 3 базы + docker-сервис * docker-сервис + база А ожидается не 8 соединений, а 50к websocket (с задержкой запросов по 1с)

без разницы, сколько одновременных соединений. accept queue — это про то, сколько должно запоминать ядро тех established соединений, которые еще не было accept-нуты приложением. потому и увеличение этой очереди нужно лишь в случае гигантских пиков новых соединений.

без разницы, сколько одновременных соединений. accept queue — это про то, сколько должно запоминать ядро тех established соединений, которые еще не было accept-нуты приложением. потому и увеличение этой очереди нужно лишь в случае гигантских пиков новых соединений.

Это понятно. Непонятно почему приложение подвисает и после 2млн запросов перестаёт принимать новые соединения (int исчёрпывается?) При этом. если уменьшить backlog до 512 - 8млн - не проблема. Пока это выглядит как магия. Пытаюсь её в более техническую плосткость перевести. Вот и спрашиваю - может идеи есть какие-то.

Мимо-предложу кстати посмотреть нагрузку по ядрам, типа mpstat -P ALL

Это понятно. Непонятно почему приложение подвисает и после 2млн запросов перестаёт принимать новые соединения (int исчёрпывается?) При этом. если уменьшить backlog до 512 - 8млн - не проблема. Пока это выглядит как магия. Пытаюсь её в более техническую плосткость перевести. Вот и спрашиваю - может идеи есть какие-то.

Конкретно с этим багом помочь не могу, надо разбираться на месте. Какой, кстати, somaxconn?

Конкретно с этим багом помочь не могу, надо разбираться на месте. Какой, кстати, somaxconn?

вроде 10240, умножал на 10. Это важно ?

вроде 10240, умножал на 10. Это важно ?

Просто, вдруг вы выставляли backlog > somaxconn. :)

Просто, вдруг вы выставляли backlog > somaxconn. :)

Посмотел прямо сейчас somaxconn = 25000 Backlog приложения - 1000 Я подбираю параметры. на этих - python-приложение подвисает. для nodejs может другие, но она пока меньше волнует.

Мимо-предложу кстати посмотреть нагрузку по ядрам, типа mpstat -P ALL

Да, ядра перегружены python-приложением. Возможно, оно тут теряет какие-то ресурсы. Сейчас делаю через балансировщик, чтобы в одно ядро/процесс было не более 10 запросов (меньше - убивает всю идею асинхронности). Кроме haproxy что такое может позволить ?) Меня сильно смущает, что python-asyncio приложения говорят - нам не нужен gunicorne - мы и так лучше. Пока это не очевидно.

Исправил - некоторую конкуренцию для async-приложений нужно создавать. Что делать с кучей вебсокетов (каждый - отдельное tcp-соединение и питону с нодой становится плохо) - вопрос.