Важно время работы, проверочные сервера убедятся что сервер стабилен и включат его в ротацию. Это как healthcheck механизм, который будет убирать сервер, если он перестал отвечал (и вес понизят).
Внутри используется OpenJDK, но технически есть возможность изменить на альтернативную реализацию.
Наверное менять просто так довольно опасно, можно попробовать сделать какие-то сравнительные тесты разных JVM, но в чем ваш интерес? В то что вы разрабатываете Libreica? :)
Но я советую для бекапов пользоваться профильными утилитами, вроде restic.net, они умеют делать дедупликацию, шифрование, снапшоты и складывать в s3 сами без монтирования.
Пользуюсь Yandex Object Storage, на 250GiB пошифрованных бекапов на холодном storage class выходит всего 180 рублей в месяц.
Если сравнить по калькуляторам cloud.yandex.ru/prices, mcs.mail.ru/storage, то получается:
* Яндекс.Облако 0.67 рублей за 1ГБ/месяц.
* MCS 1.6 рублей за 1 ГБ/месяц.
Идея про «одометры» здравая!
Но, даже если считать метрики через аккумулирующие счётчики, то возникает вопрос в дальнейшей агрегации.
Допустим мы 1 раз в 15 секунд смотрим на суммарное потребление процессорного времени с момента старта, что на графике показывать? Число ядро*15секунд? Ну неудобно как-то. Нормировать и делить на 15 секунд? Ну это уже получается средняя скорость по одометру, не совсем то.
А если пользователь выбрал агрегацию за последний месяц, и в точке хранятся почасовые данные, что показывать: сумму (одометр) или среднее (спидометр) ?:)
Есть определённые плюшки от использования unix-сокетов. Например исчезает проблема с time-wait сокетами внутри машины. Текущие механизмы recycle и reuse могут давать всплески до сотен миллисекунд. Конечно эту проблему частично решает keep-alive, но когда локальный бекенд начинает таймаутить и какой-нить nginx начинает переустанавливать сокеты — превед time-wait.
Кроме того, если достаточно большой rate i/o, то unixsocket экономит процессор по sys time, они банально дешевле для системы.
Да и мне лень смотреть в код, но если не изменяет память, там как-то всё очень плохо с backlog'ом. И бёрсты такая конструкция будет дропать.
Если это так, то это не минус, это нюанс. Для некоторых частей системы лучше быстро дропать запросы, чем зря складывать их в беклог. Если эта компонента ненапрямую отвечает пользователю (мы ведь врятли через unixsocket напрямую отвечаем тысячам пользователей?), то это даже огромная плюшка для балансера, который быстрее сможет поретраиться в другой бекенд.
Но есть минусы. Например, в случае если поток пытался сделать операцию с очередью, но у него не удалость стать «комбайном», то latency его операции может возрасти до 2ms. Если таких операций много, то и суммарное время будет большое. Более того, нить простаивает и не выполняет другую полезную работу.
И еще, допустим у меня есть поток, который так же что-то хочет сделать с очередью, и у него «получилось стать комбайном». И для того чтобы выйти из кода работы с очередью, мы должны выполнить пачку заданий, которые успели скопиться. Даже если изначальная задача была очень простой, итоговый latency может быть бОльшим нежели мы ожидаем.
Как в случае становления комбайном, так и в случае пассивного ожидания проблемы с latency могут быть серьезными.
На самом деле с такой back-off стратегией любая очередь не должна деградировать по throughput с ростом числа нитей.
Так что совсем не могу сказать что это очередь в чем-то лучше остальных по этим тестам. Хорошо бы сравнить очереди на одинаковых стратегиях back-off'а.
Ну во первых не «взлет», а более «плавное пикирование» и то, пикирование пропускной способности. Латентность при этом только растёт:)
На деле нет никакого взлёта перфоманса, просто выбрали один из вариантов trade-off'а:)
Было бы здорово добавить padding в очередь Димы Вьюкова и сравнить с Flat Combining Queue.
На счет меньшего проседания есть нюансы. Несомненно, судя по результатам мы видим что пропускная способность (throughput) снижается значительно медленней, но, из-за того что у нас теперь остальные потоки занимаются пассивным ожиданием, у них появляется дополнительный latency на ожидание.
При использовании spin-loop с CASами и добавлении полезной нагрузки можно получить меньший latency с сохранением уровня throughput. Так что тестируйте свои конкретные случаи. Flat Combining может работать медленней несмотря на результаты этих экспериментов.
Огромное спасибо за цикл статей, продолжайте в том же духе!
Довольно сомнительные результаты бенчмарков. На set/get из redis можно получить cтолько через один сокет, и есть ощущуние что все бенчмарки проводились с одним сокетом. В реальности на тех же set/get без pipeline из redis можно выжать и 250Krps. А сколько может ledis в разными бекендами не ясно.
The call notifications (Caller ID) feature is currently not available for Fitbit Force or Charge. A firmware update that provides this feature will be available soon.
Кстати если мы отключаем O_DIRECT, а внутри у нас какая-то умная база данных, которая делает свой кеш данных в памяти вместо page cache, то на деле у данные могут хранится в двух копиях. В кеше программы и page cache. При этом, вытесняя что-то полезное из page cache можно так же навредить и уменьшить производительность других контейнеров и упереться в диски на случайное чтение.
Аффинити по NUMA-нодам правда даёт снижение latency к памяти, но возможны ситуации когда процессорного времени одного сокета начинает не хватать, и тогда контейнер, который съедает всё процессорное время на numa-ноде, будет очень сильно мешать другим контейнерам на той же numa-ноде.
Польза будет в том случае, если мы упираемся в latency RAM, но не в процессорное время.
Очень страшно от хостера видеть такой комментарий!:)
Все предложенные способы конечно могут увеличить производительность, но за это приходится чем-то платить.
Если мы отключаем O_DIRECT / fsync в контейнере, то клиент имеет шанс потерять данные.
Оверкоммиты по памяти и процессору конечно уже не столь деструктивны, но и это может негативно сказаться совместном исполнении нескольких контейнеров внутри одной машины.
А какое исключение генерируется при отправке на 465 порт? На порту для ssl всё же точно должно работать.
На 25ом порту во время сессии можно включить STARTTLS, видимо smtpClient ровно это и делает.
Возможно в первом случае вы пытаетесь использовать STARTTLS под уже включенным ssl-соединением, и клиенту становится плохо:)
А есть какие-то сравнительные тесты производительности jsonb относительно обычного json?
На одной из задач где много ввода/вывода принципиальной разницы не заметил.
Важно время работы, проверочные сервера убедятся что сервер стабилен и включат его в ротацию. Это как healthcheck механизм, который будет убирать сервер, если он перестал отвечал (и вес понизят).
Внутри используется OpenJDK, но технически есть возможность изменить на альтернативную реализацию.
Наверное менять просто так довольно опасно, можно попробовать сделать какие-то сравнительные тесты разных JVM, но в чем ваш интерес? В то что вы разрабатываете Libreica? :)
Работает с любыми s3 compatible объектными хранилищами.
Но я советую для бекапов пользоваться профильными утилитами, вроде restic.net, они умеют делать дедупликацию, шифрование, снапшоты и складывать в s3 сами без монтирования.
Если сравнить по калькуляторам cloud.yandex.ru/prices, mcs.mail.ru/storage, то получается:
* Яндекс.Облако 0.67 рублей за 1ГБ/месяц.
* MCS 1.6 рублей за 1 ГБ/месяц.
Идея про «одометры» здравая!
Но, даже если считать метрики через аккумулирующие счётчики, то возникает вопрос в дальнейшей агрегации.
Допустим мы 1 раз в 15 секунд смотрим на суммарное потребление процессорного времени с момента старта, что на графике показывать? Число ядро*15секунд? Ну неудобно как-то. Нормировать и делить на 15 секунд? Ну это уже получается средняя скорость по одометру, не совсем то.
А если пользователь выбрал агрегацию за последний месяц, и в точке хранятся почасовые данные, что показывать: сумму (одометр) или среднее (спидометр) ?:)
Кроме того, если достаточно большой rate i/o, то unixsocket экономит процессор по sys time, они банально дешевле для системы.
Если это так, то это не минус, это нюанс. Для некоторых частей системы лучше быстро дропать запросы, чем зря складывать их в беклог. Если эта компонента ненапрямую отвечает пользователю (мы ведь врятли через unixsocket напрямую отвечаем тысячам пользователей?), то это даже огромная плюшка для балансера, который быстрее сможет поретраиться в другой бекенд.
Какая интересная фамилия у него:)
И еще, допустим у меня есть поток, который так же что-то хочет сделать с очередью, и у него «получилось стать комбайном». И для того чтобы выйти из кода работы с очередью, мы должны выполнить пачку заданий, которые успели скопиться. Даже если изначальная задача была очень простой, итоговый latency может быть бОльшим нежели мы ожидаем.
Как в случае становления комбайном, так и в случае пассивного ожидания проблемы с latency могут быть серьезными.
На самом деле с такой back-off стратегией любая очередь не должна деградировать по throughput с ростом числа нитей.
Так что совсем не могу сказать что это очередь в чем-то лучше остальных по этим тестам. Хорошо бы сравнить очереди на одинаковых стратегиях back-off'а.
На деле нет никакого взлёта перфоманса, просто выбрали один из вариантов trade-off'а:)
На счет меньшего проседания есть нюансы. Несомненно, судя по результатам мы видим что пропускная способность (throughput) снижается значительно медленней, но, из-за того что у нас теперь остальные потоки занимаются пассивным ожиданием, у них появляется дополнительный latency на ожидание.
При использовании spin-loop с CASами и добавлении полезной нагрузки можно получить меньший latency с сохранением уровня throughput. Так что тестируйте свои конкретные случаи. Flat Combining может работать медленней несмотря на результаты этих экспериментов.
Огромное спасибо за цикл статей, продолжайте в том же духе!
Ждём-с вообщем, фича будет полезна:)
Просто всегда нужно знать что можно крутить и к чему это может привести:)
Кстати если мы отключаем O_DIRECT, а внутри у нас какая-то умная база данных, которая делает свой кеш данных в памяти вместо page cache, то на деле у данные могут хранится в двух копиях. В кеше программы и page cache. При этом, вытесняя что-то полезное из page cache можно так же навредить и уменьшить производительность других контейнеров и упереться в диски на случайное чтение.
Аффинити по NUMA-нодам правда даёт снижение latency к памяти, но возможны ситуации когда процессорного времени одного сокета начинает не хватать, и тогда контейнер, который съедает всё процессорное время на numa-ноде, будет очень сильно мешать другим контейнерам на той же numa-ноде.
Польза будет в том случае, если мы упираемся в latency RAM, но не в процессорное время.
Все предложенные способы конечно могут увеличить производительность, но за это приходится чем-то платить.
Если мы отключаем O_DIRECT / fsync в контейнере, то клиент имеет шанс потерять данные.
Оверкоммиты по памяти и процессору конечно уже не столь деструктивны, но и это может негативно сказаться совместном исполнении нескольких контейнеров внутри одной машины.
На 25ом порту во время сессии можно включить STARTTLS, видимо smtpClient ровно это и делает.
Возможно в первом случае вы пытаетесь использовать STARTTLS под уже включенным ssl-соединением, и клиенту становится плохо:)
На одной из задач где много ввода/вывода принципиальной разницы не заметил.