В похожей ситуации использовали такой подход: m3u динамический, плейлисты отдаются высокопроизводительным бэкендом. Там высокий rps, но нет io, и сами плейлисты мелкие, поэтому bandwidth не занят у серверов.
При генерации плейлиста учитывалась нагрузка на серверы, отдающие непосредственно видеочанки. Серверы выводились из балансировки при недоступности, или когда полоса была на пределе. А ещё автоматом подкидывалась раздача через cdn, когда полоса всех серверов группы была близка к пределу
Мне вот тоже интересно - вы все видео смотрите из кафе через одноразовую виртуальную машину? А капюшон накидываете, чтобы камера в кафе вас не засняла в этот момент?
Если вы запустите джобу 2 раза у вас будет 2 собранных образа или один? А если два, то будут ли они одинаковые, или могу получиться разные? А если они запустятся на двух разных раннерах? Должна ли сборка, запущенная дважды на одном коммите давать одинаковый результат или может давать разный?
Не рассмотрен ещё один компромиссный (и, конечно же, спорный) вариант:
Допустим, ваше приложение в отсутствии лимитов потребляет 200m cpu, и работает на нодах с 4 или 8 ядрами. В некоторых случаях имеет смысл поставить лимит 2000m cpu (2 ядра). Скорее всего, при нормальном режиме работы приложения, троллинга никогда не случится. Но если что-то пойдет не так, например из-за ошибки в коде приложения, или из-за dos атаки на него, то приложение "не съест" всю ноду и всё-таки будет тротлиться.
У нас в городе Ростелеком ставит PON-терминалы Eltex. В одной квартире я устройство приобрел. Потом переехал в другую квартиру и, при попытке подключить Ростелеком, встал перед выбором: аренда точно такой же модели, как у меня в руках, покупка новой такой же или... заплатить за настройку pon терминала. Настройка вероятно заключалась в прописывании id pon-терминала на головной станции, и оценивалась оператором, если память не изменяет, в 1500р.
Могут сказать: не хочешь платить за аренду - можешь купить.
Причем если у тебя уже есть роутер с gpon, который подходит к этой сети, то просто так воспользоваться ты им не сможешь, нужно "заплатить за настройку". Потому что настройка на стороне оператора выполняется, и она платная.
В общем без оплаты навязанных сервисов никак не соскочить.
Подключил лет 5-7 назад эту самую "симку в сейфе". На счёт кинул 300тг. Их должно было хватить условно на четверть века (1тг/мес)
Итог: пару лет назад вставил симку в телефон, она не работает. На сайте раньше можно было попасть в ЛС по паролю, но новая версия только по коду из СМС, который не приходит очевидным образом на не работающую симку.
"Выходцы из Яндекса"- это значит, что их что-то не устроило в Яндексе, они оттуда вышли и потом основали свои стартапы? Потому что в Яндексе эти идеи продвигать или не получалось, или было не выгодно?
Частая ситуация, когда "в ходе удаления и систематизации данных" дисковое пространство, занимаемое БД, растёт. И чем больше данных вы якобы "удаляете", тем больше места будет занято. То есть, если у вас диск занят на 70%, и вы "удаляете" половину данных, то одномоментно можете получить прирост на 50% от занятого, то есть диск в итоге будет переполнен. И это можно сделать всего одним, на вид безобидным, запросом SQL.
Про мониторинг все конечно верно, но тут явно не этот случай, когда "проворонили, что место кончилось". Очевидно, что инцидент связан именно с оптимизацией данных.
Сложно понять, что имеется ввиду под "готов для продакшн", поэтому и ответить на такой вопрос сложно.
Я слышал, что Linux написал какой-то финский судент, и, хотя проект развивается уже десятки лет, там всё ещё тысячи open issues на https://bugzilla.kernel.org
Тем не менее некоторые используют Linux в production environment. Но, как вы понимаете продакшн продакшну рознь, тут конечно каждый сам решает, подойдёт ли им Linux или пока нет. Тоже самое с external secrets operator - если у вас очень ответственный продакшн, то, возможно, и external secrets operator и Linux использовать пока рановато.
Например мы рискнули и начали использовать в продакшн и Linux, и Kubernetes, и External secrets operator. Если говорить про количество возникших проблем, то с external secrets operator за все время эксплуатации (около полугода) их не было совсем. А больше всего проблем было с Linux.
Имея такую статистику можно сделать (неправильный) вывод, что проект External secrets operator на голову лучше и стабильнее, чем Linux.
Ну а если кроме шуток, то оператор очень не плох, нам нравится и мы используем его в продакшн. И как я писал выше - проблем (пока) не было.
То есть когда редис будет практически заполнен, и вы добавите туда новый ключ, то при добавлении следующего нового ключа ваш только что добавленный сразу будет удален? Ведь он наименее "популярный". Спорно.
В похожей ситуации использовали такой подход: m3u динамический, плейлисты отдаются высокопроизводительным бэкендом. Там высокий rps, но нет io, и сами плейлисты мелкие, поэтому bandwidth не занят у серверов.
При генерации плейлиста учитывалась нагрузка на серверы, отдающие непосредственно видеочанки. Серверы выводились из балансировки при недоступности, или когда полоса была на пределе. А ещё автоматом подкидывалась раздача через cdn, когда полоса всех серверов группы была близка к пределу
Мне вот тоже интересно - вы все видео смотрите из кафе через одноразовую виртуальную машину? А капюшон накидываете, чтобы камера в кафе вас не засняла в этот момент?
Я - нет
Если вы запустите джобу 2 раза у вас будет 2 собранных образа или один? А если два, то будут ли они одинаковые, или могу получиться разные? А если они запустятся на двух разных раннерах? Должна ли сборка, запущенная дважды на одном коммите давать одинаковый результат или может давать разный?
Не рассмотрен ещё один компромиссный (и, конечно же, спорный) вариант:
Допустим, ваше приложение в отсутствии лимитов потребляет 200m cpu, и работает на нодах с 4 или 8 ядрами. В некоторых случаях имеет смысл поставить лимит 2000m cpu (2 ядра). Скорее всего, при нормальном режиме работы приложения, троллинга никогда не случится. Но если что-то пойдет не так, например из-за ошибки в коде приложения, или из-за dos атаки на него, то приложение "не съест" всю ноду и всё-таки будет тротлиться.
Немного глаза режет мл.сек. Миллилитров секунд? Почему не мсек? По-русски должно быть или милли или м.
https://ru.m.wikipedia.org/wiki/Приставки_СИ
Ну я описывал конкретный случай из жизни.
У нас в городе Ростелеком ставит PON-терминалы Eltex. В одной квартире я устройство приобрел. Потом переехал в другую квартиру и, при попытке подключить Ростелеком, встал перед выбором: аренда точно такой же модели, как у меня в руках, покупка новой такой же или... заплатить за настройку pon терминала. Настройка вероятно заключалась в прописывании id pon-терминала на головной станции, и оценивалась оператором, если память не изменяет, в 1500р.
Могут сказать: не хочешь платить за аренду - можешь купить.
Причем если у тебя уже есть роутер с gpon, который подходит к этой сети, то просто так воспользоваться ты им не сможешь, нужно "заплатить за настройку". Потому что настройка на стороне оператора выполняется, и она платная.
В общем без оплаты навязанных сервисов никак не соскочить.
Скоро изобретут ассемблер на python
При этом списание с баланса за эту услугу не является "платным действием" и не останавливает платные списания )
Подключил лет 5-7 назад эту самую "симку в сейфе". На счёт кинул 300тг. Их должно было хватить условно на четверть века (1тг/мес)
Итог: пару лет назад вставил симку в телефон, она не работает. На сайте раньше можно было попасть в ЛС по паролю, но новая версия только по коду из СМС, который не приходит очевидным образом на не работающую симку.
"Выходцы из Яндекса"- это значит, что их что-то не устроило в Яндексе, они оттуда вышли и потом основали свои стартапы? Потому что в Яндексе эти идеи продвигать или не получалось, или было не выгодно?
Частая ситуация, когда "в ходе удаления и систематизации данных" дисковое пространство, занимаемое БД, растёт. И чем больше данных вы якобы "удаляете", тем больше места будет занято. То есть, если у вас диск занят на 70%, и вы "удаляете" половину данных, то одномоментно можете получить прирост на 50% от занятого, то есть диск в итоге будет переполнен. И это можно сделать всего одним, на вид безобидным, запросом SQL.
Про мониторинг все конечно верно, но тут явно не этот случай, когда "проворонили, что место кончилось". Очевидно, что инцидент связан именно с оптимизацией данных.
Поздравляю ребят, молодцы!
Причину нашли?
В паблике нет чарта, но в общем-то за основу был взят этот https://github.com/Enapter/charts
В этом блоке были добавлены "внешние" инстансы, поднятые на hostport, добавленные тут
Сложно понять, что имеется ввиду под "готов для продакшн", поэтому и ответить на такой вопрос сложно.
Я слышал, что Linux написал какой-то финский судент, и, хотя проект развивается уже десятки лет, там всё ещё тысячи open issues на https://bugzilla.kernel.org
Тем не менее некоторые используют Linux в production environment. Но, как вы понимаете продакшн продакшну рознь, тут конечно каждый сам решает, подойдёт ли им Linux или пока нет. Тоже самое с external secrets operator - если у вас очень ответственный продакшн, то, возможно, и external secrets operator и Linux использовать пока рановато.
Например мы рискнули и начали использовать в продакшн и Linux, и Kubernetes, и External secrets operator. Если говорить про количество возникших проблем, то с external secrets operator за все время эксплуатации (около полугода) их не было совсем. А больше всего проблем было с Linux.
Имея такую статистику можно сделать (неправильный) вывод, что проект External secrets operator на голову лучше и стабильнее, чем Linux.
Ну а если кроме шуток, то оператор очень не плох, нам нравится и мы используем его в продакшн. И как я писал выше - проблем (пока) не было.
А какой коннекшн-рейт? Размер ключей?
Что в keydb было - простой key/value , а может быть очереди или geohash запрашивали?
тут обсуждали https://habr.com/ru/companies/flant/articles/700294/#comment_24948404
.
То есть когда редис будет практически заполнен, и вы добавите туда новый ключ, то при добавлении следующего нового ключа ваш только что добавленный сразу будет удален? Ведь он наименее "популярный". Спорно.
А чем не устроил redis-exporter?
Тема aof vs rdb не раскрыта. Как и тема diskless репликации. И шардирования
И многопоточности.
Можно наверное что-то про это добавить.
А какого размера редис если не секрет?
А пробовали хранить сжатые данные?