Комментарии 14
А на сколько по cpu загружены эти 16 серверов, расссылающие ~1ккк пушей через питончик?
на 60-70%
Присоединяюсь к вашему треду, раз он вроде бы как про загрузку серверов.
shveenkov, позвольте полюбопытствовать. Вы упомянули, что сервера Tarantool медленно запускались со своими 50 Гб памяти (или сколько ему надо было), вы бы могли сказать как долго?
И что в этом случае было лимитирующим фактором (например, загрузить в память 50 Гб, или что-нибудь ещё).
И насколько большие были у вас сервера для того, чтобы обеспечить, как я понимаю, ~12k уведомлений в секунду?
Спасибо
shveenkov, позвольте полюбопытствовать. Вы упомянули, что сервера Tarantool медленно запускались со своими 50 Гб памяти (или сколько ему надо было), вы бы могли сказать как долго?
И что в этом случае было лимитирующим фактором (например, загрузить в память 50 Гб, или что-нибудь ещё).
И насколько большие были у вас сервера для того, чтобы обеспечить, как я понимаю, ~12k уведомлений в секунду?
Спасибо
Рестарт tarantool длился «минуты», 10-15 минут, не больше, предварительно нужно было сделать снапшот, это еще 10-15 минут, точнее время не назову. Во время снапшота — мастер работает и доступен на запись.
На сервере с tarantool память вся отдана ему. Других процессов нет.
Да ~12k — 15k уведомлений в секунду рассылают 8 серверов:
Intel® Xeon® CPU E5-2620 0 @ 2.00GHz
24 ядра
памяти — 32Гб
жесткие диски — обычные sata
Про лимитирующий фактор не совсем понял, поясните чуть подробнее что имелось ввиду?
На сервере с tarantool память вся отдана ему. Других процессов нет.
Да ~12k — 15k уведомлений в секунду рассылают 8 серверов:
Intel® Xeon® CPU E5-2620 0 @ 2.00GHz
24 ядра
памяти — 32Гб
жесткие диски — обычные sata
Про лимитирующий фактор не совсем понял, поясните чуть подробнее что имелось ввиду?
Я так понимаю, «лимитирующий фактор» — во что упирался тарантул, тратя столько времени на запуск.
Для запуска за 10 минут похоже (ну, более-менее) в скорость чтения диска.
Для запуска за 10 минут похоже (ну, более-менее) в скорость чтения диска.
да, спасибо, вы правильно меня поняли. Обычно старт долги бывает, что мы упёрлись в какой-нибудь bottleneck. Будь это загрузка с диска, или обработка процессором чего-нибудь в памяти (например, проверка целостности). Как-то так.
Наверняка ваши разработчики имели возможность сделать профайлинг, чтобы узнать где вы просели.
Опять же, это полезно знать, когда я (предположим) имею 100 Гб данных на диске (и соответственно необходимую память на сервере), то старт моего сервера будет зависеть от скорости чтения.
Наверняка ваши разработчики имели возможность сделать профайлинг, чтобы узнать где вы просели.
Опять же, это полезно знать, когда я (предположим) имею 100 Гб данных на диске (и соответственно необходимую память на сервере), то старт моего сервера будет зависеть от скорости чтения.
Уже с сентября прошлого года в бете версии 1.7.* tarantool'а, а также есть слухи о тестировании и скором выходе версии 1.8 с поддержкой sql. Насколько будет оправдан переход на эти версии и насколько будет сложна миграция между ними?
У tarantool 1.6, 1.7, 1.8 — одинаковый протокол с msgpack внутри.
Думаю сложностей быть не должно.
Кроме sql еще много всего интересного, например движок винил.
Было бы интересно попробовать его для хранения данных.
Думаю сложностей быть не должно.
Кроме sql еще много всего интересного, например движок винил.
Было бы интересно попробовать его для хранения данных.
Хотелось бы поскорее уже во всю мощь потрогать руками связку vinyl + sql!
А как Вы эффективно сортируете данные по разным полям?
Единственное решение, которое я сейчас вижу(и использую) это создание индексов для всех полей, по которым надо сортировать(+если используется выборка по полю 1, а сортировка нужна по полю 2 или 3, приходится создавать 2 индекса: 1, 2 и 1, 3)
В таком случае получается достаточно много индексов, а также накладывается ограничение, что это поле не может содержать nil
А как Вы эффективно сортируете данные по разным полям?
Единственное решение, которое я сейчас вижу(и использую) это создание индексов для всех полей, по которым надо сортировать(+если используется выборка по полю 1, а сортировка нужна по полю 2 или 3, приходится создавать 2 индекса: 1, 2 и 1, 3)
В таком случае получается достаточно много индексов, а также накладывается ограничение, что это поле не может содержать nil
Кстати, если в apns пуши отсылаются по старой схеме с бинарным tcp без подтверждения успешного получения, то откуда время обработки в ~40мс? Или это время до отправки в сокет, а время ожидания feedback'а сюда не входит?
Время ожидания feedback'а сюда не входит.
На графике показано суммарное время на обработку сообщения, т.е. не только отправка в сокет.
Для отправки сообщения нужно сходить в тарантул, сделать проверки, сформировать json, упаковать и отправить бинарные данные в ios.
Время обработки ухудшилось из-за проблем с proxy, желтый график без прокси — на нем время хорошее.
Сейчас суммарное время составляет 3-4мс.
На графике показано суммарное время на обработку сообщения, т.е. не только отправка в сокет.
Для отправки сообщения нужно сходить в тарантул, сделать проверки, сформировать json, упаковать и отправить бинарные данные в ios.
Время обработки ухудшилось из-за проблем с proxy, желтый график без прокси — на нем время хорошее.
Сейчас суммарное время составляет 3-4мс.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Переходим c Tarantool 1.5 на 1.6