Size: a a a

2020 October 16

SA

Sergey Arkhipov in rannts
источник

VD

Vladimir Deev in rannts
Sergey Arkhipov
Такие схемы и правда совсем ненадежные, хрупкие и причиняют много багов. А что если какой-то процесс должен был рестартовать, а не рестартовал? А если другой процесс рестартовали? А если там чего-то неправильно пошло?

В случае "опс" надо думать не о happy path, а о том, что может пойти не так, и как бы сделать систему более предсказуемую.

Пока что лучшее, с чем я работал - это blue/green deployment. То есть рядом стартуем инстанс, ждем, пока он не станет работать, а затем переводим трафик на него, а старый graceful shutdown'им. Так работает Marathon + при определенных настройках кубернетес.

Это и без докера делается, кстати. Капистрано позволяет что-то подобное организовать в пределах одного хоста. Там суть простая - деплоим приложение в другую директорию, стартуем, добавляем еще один апстрим nginx'а, затем nginx reload и ждем, пока новое приложение не оклемается. Оклемалось - SIGINT в старое и ждем, пока оно не доработает. Доработало - убиваем.

Это Zero Downtime, однако в то же время, самая надежная схема сделать подобные вещи, особенно если хелсчеки, liveness/readiness probes реально проверяют чего-то внутри инстанса
о как, спасибо за развернутый ответ)
источник
2020 October 19

RB

Roman Bolkhovitin in rannts
леди и джентльмены, а у вас же есть монга в проде?

пытаемся выбраться из 2014 года, обновились с 2.6 до 3.4 (были причины не обновляться сразу до 4+), потом переключили одну из реплик на WiredTiger и она работает, но админ жалуется, что слишком активно пишет на диск по сравнению со старым движком и боится что ssd сдохнут раньше чем им было отмерено боженькой

у меня есть только картинки из atop, там где циферки поменьше это всегда так, а там где побольше это раз в минуту

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

может кто знает, надо переживать по этому поводу или так и должно быть?
источник

RB

Roman Bolkhovitin in rannts
источник

RB

Roman Bolkhovitin in rannts
источник

KK

Kirill (Cykooz) Kuzm... in rannts
Мы обновлялись в своё время потихоньку на все новые версии и у нас таких вопросов не возникало. Наверное мы просто не мониторили нагрузку на диск и нам было пофиг на неё если и так всё работает.
источник

БС

Байт Словович... in rannts
Я не понял где что искать  в картинках.. Скажи сколько было IOPSов и сколько стало
источник

AS

Artem Savinov in rannts
Kirill (Cykooz) Kuzminykh
Мы обновлялись в своё время потихоньку на все новые версии и у нас таких вопросов не возникало. Наверное мы просто не мониторили нагрузку на диск и нам было пофиг на неё если и так всё работает.
вы в ВМ работаете, а они видимо на железе(поправь плиз елси не прав)
источник

KK

Kirill (Cykooz) Kuzm... in rannts
Ну скорее всего да. В любом случае не помню что бы мы беспокоились о сроке жизни SSD дисков. Лишь бы всё работало и не тормозило.
источник

RB

Roman Bolkhovitin in rannts
Байт Словович
Я не понял где что искать  в картинках.. Скажи сколько было IOPSов и сколько стало
это я хз, iostat нет или у меня прав нет )
табличку из atop читаю вот по такой мурзилке

 Such line shows the name (e.g. VolGroup00-lvtmp for a logical volume or sda for a hard disk), the busy percentage i.e. the portion of time that the unit was busy handling requests ('busy'), the number of read requests issued ('read'), the number of write requests issued ('write'), the number of KiBytes per read ('KiB/r'), the number of KiBytes per write ('KiB/w'), the number of MiBytes per second throughput for reads ('MBr/s'), the number of MiBytes per second throughput for writes ('MBw/s'), the average queue depth ('avq') and the average number of milliseconds needed by a request ('avio') for seek, latency and data transfer.
источник

БС

Байт Словович... in rannts
то есть вместо 6 тысячи write стало 40 тысяч? Это за какой период?
источник

БС

Байт Словович... in rannts
это столько под нагрузкой??
источник

RB

Roman Bolkhovitin in rannts
не, 6 тысяч постоянно держится, я думаю что это journal (типа write ahead log что-то) а до 40 прыгает раз в минуту, когда этот журнал в персистент вид сливается.

а на инстансах со старым движком ~2000 и 20_000 соответственно
источник

RB

Roman Bolkhovitin in rannts
Байт Словович
это столько под нагрузкой??
да, на проде
источник

AS

Artem Savinov in rannts
ну по %  загруженности этот nvme еще больше может перемолотить
источник

AS

Artem Savinov in rannts
понятно что если его "за.." сдохнет быстрее, но нафига вы тогда их брали
источник

БС

Байт Словович... in rannts
Roman Bolkhovitin
не, 6 тысяч постоянно держится, я думаю что это journal (типа write ahead log что-то) а до 40 прыгает раз в минуту, когда этот журнал в персистент вид сливается.

а на инстансах со старым движком ~2000 и 20_000 соответственно
ну домашние SSD выдают порядка 20к IOPS.. У тебя 40к, но вроде нет лимита что это прям надо сделать за секунду, поэтому в диск вы не должны упираться.  Насколько это сократит время жизни SSD, тяжело сказать, но я не слышал чтобы кто-то этим замарачивался. Диски считаются расходником, к тому же они стали достаточно дешевыми.

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

RB

Roman Bolkhovitin in rannts
да, согласен, за диски переживать бред какой-то, просто думал может кто в курсе особенностей движков и почему на MMAPv1 такой нагрузки намного меньше чем на WT )
источник

A🌚

Al 🌚l in rannts
Байт Словович
ну домашние SSD выдают порядка 20к IOPS.. У тебя 40к, но вроде нет лимита что это прям надо сделать за секунду, поэтому в диск вы не должны упираться.  Насколько это сократит время жизни SSD, тяжело сказать, но я не слышал чтобы кто-то этим замарачивался. Диски считаются расходником, к тому же они стали достаточно дешевыми.

Если это прям проблема, то надо смотреть на базу и понять почему там много записей у вас получается. Может вы где то не эффективно используете монгу и делаете лишние запросы.
Проверять это либо глазками все запросы к монге, либо делать лоадтест и прикидывать сколько значений вы меняете в этом тесте. Если IOPSов больше, чем на пальцах считается, то значит надо смотреть запросы и искать лишние
Вот летит же время. Ещё совсем недавно было хер купить nvme ssd себе. А щас они уже в расходники записываются
источник

A🌚

Al 🌚l in rannts
Ну «недавно»)
источник