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

+

меня больше смущает например релоад нжинкса с 50к сертов на сервере.

Это занимает *какое-то время* :)

И память жрет.

меня больше смущает например релоад нжинкса с 50к сертов на сервере.

меня смущает 50k серверов в конфиге nginx. начнем с этого :)))))

Ну, кластер, который швыряет коннекты дальше

что такоен роллинг деплой микробаз раз в секунду? это вообще зачем?

мм, не понял вопрос.

в мапе прям все домены хостинга.

И да, да, я знаю, что по-хорошему его надо разделять на куски

мм, не понял вопрос.

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

Ну, кластер, который швыряет коннекты дальше

А тут уже стрим нужно.

И да, да, я знаю, что по-хорошему его надо разделять на куски

Ну тогда надо или вздохнуть и терпеть. Или держать пару, переключая между ними

Ну тогда надо или вздохнуть и терпеть. Или держать пару, переключая между ними

Я в efind так кстати склады обновлял. Обновил - поставил галочку active

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

задача была - поисковик картинок. 3ккк картинок + поисковый индекс. поисковый индекс делится на шарды, шарды индекса отражаются 1:1 к шардам хранилища картинок. шарды хранилища картинок представляют из себя серверы, которые умеют отдавать картинки :) де-факто это просто сервер со статикой. когда мы катим новый индекс, мы одновременно катим и новые картинки. мы не можем позволить себе blue-green-деплой в таком режиме (огромный простой железа), поэтому индекс и картинки деплоятся роллингом. роллинг - это значит что за раз деплоится несколько шардов из 2048. процесс последовательный и долгий. при окончании деплоя шарда индекса и шарда хранилища происходит переконфигурация nginx'ов, потому что шарды хранилища складываются на наиболее свободные машины хранилища, а соответствующие старые шарды удаляются.

аааа

все равно понял только интуитивно, но ладно

спасибо ;)

задача была - поисковик картинок. 3ккк картинок + поисковый индекс. поисковый индекс делится на шарды, шарды индекса отражаются 1:1 к шардам хранилища картинок. шарды хранилища картинок представляют из себя серверы, которые умеют отдавать картинки :) де-факто это просто сервер со статикой. когда мы катим новый индекс, мы одновременно катим и новые картинки. мы не можем позволить себе blue-green-деплой в таком режиме (огромный простой железа), поэтому индекс и картинки деплоятся роллингом. роллинг - это значит что за раз деплоится несколько шардов из 2048. процесс последовательный и долгий. при окончании деплоя шарда индекса и шарда хранилища происходит переконфигурация nginx'ов, потому что шарды хранилища складываются на наиболее свободные машины хранилища, а соответствующие старые шарды удаляются.

Это немного специфичнее хостинга схема. И кстати здесь-то как раз можно серт просто подписывать там, где HTTPS слушает.

Ну то есть зачем все машины хранилища тут трогать.

Это немного специфичнее хостинга схема. И кстати здесь-то как раз можно серт просто подписывать там, где HTTPS слушает.

здесь не было проблем по деплою ssl. я просто привел пример разросшейся конфигурации, которая требовала частых релоадов.

Ммм ок.

Деплой микробаз и перераскатка наносервисов

Пикодеплой

Боку но пико деплой

милликомитами

Деплой микробаз и перераскатка наносервисов

микробазы, хм, называются так, потому что в контексте сервиса они маленькие, а не потому что они весят 100 кб :)

микробазы, хм, называются так, потому что в контексте сервиса они маленькие, а не потому что они весят 100 кб :)

а что такое микробазы кстати?

хотя я и про шардинг индексов бы почитал

микробаза - почти синоним шарду

а про шард? и индексов. да и не инлексов тоже.

мм, я там больше не работаю, цикл статей как это было устроено в мейлрушке вот: https://habrahabr.ru/company/mailru/blog/167297/

метапоиск отправлял запрос во все шарды параллельно, они отвечали "у меня есть 620 документов", или "у меня есть 0 документов", после этого метапоиск выбирал шарды, которые потенциально интересны и отправлял запрос туда (вторая стадия), откуда получал уже ответы, переранжировал их и возможно делал дозапрос, снова переранжировал и отправлял пользователю.

метапоиск отправлял запрос во все шарды параллельно, они отвечали "у меня есть 620 документов", или "у меня есть 0 документов", после этого метапоиск выбирал шарды, которые потенциально интересны и отправлял запрос туда (вторая стадия), откуда получал уже ответы, переранжировал их и возможно делал дозапрос, снова переранжировал и отправлял пользователю.

напоминает то как у нас графит работает )

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

Задача состоит в построении массива данных в виде направленного весового графа Минимальная единица массива отдельное слово. Должна быть возможность устанавливать связи между отдельными объектами, а также между выделенными группами, и между группами, каждая из которых объединяет другие группы. Не менее 10 уровней вложений. Необходимо реализовать, динамическое выделение любой части массива, любого размера и неопределенной формы. И иметь возможность отслеживать время последнего обращения к любому объекту, группе и связи.

Titandb немного подходит, но он мертв

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

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

выборка по клиентам потому как

пол, возраст, геолокация etc

один фиг не понимаю зачем это всё в почту пихать

там ещё было слово пушки

пушек больше на самом деле

json с описанием пушки и массив токенов длинной до 152 символов в количестве 1000 штук "в идеале" это одно сообшение таких сообщений в очереди на отправку может быть до 5 десятков вот так

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

А где узкое место?

шо ты имеешь в виду?

шо ты имеешь в виду?

Ну “почтовые очереди” вроде были чуть ли не с начала времён. Какая часть системы загибается?

балин

json с описанием пушки и массив токенов длинной до 152 символов в количестве 1000 штук "в идеале" это одно сообшение таких сообщений в очереди на отправку может быть до 5 десятков вот так

почта это побочный продукт, не привязывайтесь к почте

я собираю мнения как лучше эту очередь реализовать. Были мысли про рэббит, но 100% загнётся в один прекрасный момент, т.к. не рассчитан на хранение таких объёмов данных

при чём в случае с кластером он загнётся быстрее чем с одно нодой

в соседнем чате посоветовали celery посмотреть

а что надо то в результате?

ну приходят и приходят, что с них взять

нужна очередь достаточно объёмных сообщений

всё

вся задача

у celery разные бекенды были, кмк. но эта вся пачка json около 30Мб максимум получается, не так уж и много вроде

для ребита много

тут ещё важно, что бы хранилище было не inmemory как в случае с редисом

нужна очередь достаточно объёмных сообщений

кафка?

да, тоже предлагали

тред не читал

))

50 месседжей по метру?

@uncle_gaara кафка это хороший выбор )

ERROR: S client not available

@uncle_gaara кафка это хороший выбор )

так вот давайте без троллинга ))

так вот давайте без троллинга ))

никакого троллинга. кафка - хороша.

так вот давайте без троллинга ))

это не троллинг, а подтверждение правильности прошлых ораторов

вот так верю

какие подводные камни? )

какие подводные камни? )

кровь-кишки-распидорасило в определенный момент...

плохо

)))

для ребита много

мне кажется даже сообщения в мегабайт не уложит реббита

но 50 сообщений по 1MB это не так уж много, если Я правильно понял постановку задачи

на самом деле кафка норм и совсем кровь-кишки я не получал.

уложит уложит

кафка тоже норм, рядом сидят люди, которые ей в продакшене довольны

значит покурим кафку и селери

значит покурим кафку и селери

http://docs.celeryproject.org/en/latest/getting-started/brokers/index.html селери сама по себе не хранит очередь, хранят брокеры: редис или кролик

Ребят

Смотрите, нужно костыльнуть.

есть имидж с приложением.

есть задача запустить порядка 30 инстансов этого аппа с одним параметром (--run-once) дождаться пока они все завершаться и запустит ьс другим параметром (--calc)

как бы вы поступили ?

Эээ, простейший скрипт с wait?

echo {0..30} | xargs -P 30 -n 1 docker run ... .... ; echo {0..30} | ....

echo | xargs ЗАЧЕМ

параллельно

Вот за что вас, девопсов, не любят! :D

cmd & wait

xargs в parallel разве будет ждать заврешения всех этих процессов ?

xargs при должном применении - вообще мапредьюс-фреймворк.

Девопсы в чате?

cmd & wait не получится дождаться выполнения всех 30 контейнеров перед тем как стартовать дополнительные.

Што

Во-первых, никто не сказал ничего про контейнеры изначально