Pull to refresh
8
0
Mikhail Epikhin @sch1z0phr3n1a

Site Reliability Engineer

Send message

Внутри используется OpenJDK, но технически есть возможность изменить на альтернативную реализацию.

Наверное менять просто так довольно опасно, можно попробовать сделать какие-то сравнительные тесты разных JVM, но в чем ваш интерес? В то что вы разрабатываете Libreica? :)

Да, через s3fs github.com/s3fs-fuse/s3fs-fuse cloud.yandex.ru/docs/storage/instruments/s3fs
Работает с любыми s3 compatible объектными хранилищами.

Но я советую для бекапов пользоваться профильными утилитами, вроде 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 напрямую отвечаем тысячам пользователей?), то это даже огромная плюшка для балансера, который быстрее сможет поретраиться в другой бекенд.
Министр сельского хозяйства Шотландии Ричард Лоххед

Какая интересная фамилия у него:)
exit-ноды держите в России? Что-то логируете не случай если напишут люди из органов?
А почему вы считаете что SMTPS устаревший?
Но есть минусы. Например, в случае если поток пытался сделать операцию с очередью, но у него не удалость стать «комбайном», то 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?
На одной из задач где много ввода/вывода принципиальной разницы не заметил.
Спасибо, на проблемном стенде как раз был THP. Попробуем HugePages.
1
23 ...

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity