Pull to refresh
35
0
Андрей Сумин @Montmorency

Руководитель группы бэкенд-разработки @ hh.ru

Send message
Появилась в 8u191 в октябре 2018

Спасибо за статью. Скажите, пожалуйста, сколько примерно времени у вас ушло на разработку системы уровней и на внедрение системы оценки?

Передал этот вопрос нашей команде эксплуатации:
Экономия по оперативной памяти — в kvm виртуалке свое ядро, система и стек приложений, на это 500-1000MB памяти надо закладывать, а это примерно двойной оверхед для мелких сервисов. Плюс контейнер может отдать память в систему сразу, а виртуалка только после рестарта (kvm baloon у нас приводил к проблемам).

По объёму и пропускной способности диска ещё выиграли — на каждую виртуалку раньше выделяли образ минимум по 10GB, c учётом того что у нас до 30 контейнеров на хост — это уже значительный оверхед на пустом месте, потому что большая часть железа работает в блейдах, где максимум 2 диска 2.5". И в нехватку дискового пространства гораздо чаще бы упирались — предсказать сколько места понадобится заранее не всегда возможно.

Производительность дисковой подсистемы с kvm отличается в разы от хостовой с некоторыми драйверами, до 200% оверхеда спокойно могло быть в некоторых случаях.

Ну и оверхед управления этим всем — рулить 1000 виртуалок вместо 1000 контейнеров с учётом прочих задач — это ещё наверное пару человек пришлось бы нанимать (тот же ресайз образа виртуалки это не самая быстрая задача, + ковыряние с srv-iov и настройками на каждой виртуалке). Релизы бы стали медленнее, если бы каждый плейбук еще системные конфиги на машины приносил, как было раньше
Я немного не о том. JVM (насколько я понимаю этот механизм) при создании треда вызывает pthread_attr_setstacksize со значением, высчитанным как раз из ThreadStackSize.

pthread_attr_setstacksize задаёт минимальный размер стека (он же становится максимальным для не-main треда): man7.org/linux/man-pages/man3/pthread_attr_setstacksize.3.html
Если не трудно — можете озвучить? (понятно, что многое зависит от конкретных сервисов, профиля нагрузки, я старался по это оговаривать) Возможно смогу более развёрнуто что-то изложить.
Попробую развернуть)
Чем меньше арен, тем больше contention при использовании malloc. Теоретически это может привести к деградации производительности (тут всё зависит от приложения — насколько интенсивно в нём используется malloc).
На наших типовых сервисах мы не заметили никакого проседания при уменьшении числа арен с 640 (8 * 80) до 4. Ещё меньше ставить не пробовали, так как стали повсеместно внедрять jemalloc.
Спасибо за вопросы, попробую ответить по пунктам.

1. Честно говоря, не припомню, чтобы документация описывала ThreadStackSize как максимальный размер стека. Пруфа в виде ссылки на код у меня, к сожалению, под рукой нет, однако практика показывает, что объём закоммиченной под пул Threads памяти (по показаниям native memory tracking) уменьшается с уменьшением -XX:ThreadStackSize, независимое подтверждение есть у Алексея Шипилева в JVM Anatomy Quark #12: Native Memory Tracking.

2. На графике изображён именно RSS (метрика, которую сообщает cgroups). Большое число арен (которое масштабируется по числу цпу на хосте) ведёт к неоправданной фрагментации памяти, естественно это отражается на RSS.

3 и 4. Да, вы правы, от ограничения CodeCache и Metaspace JVM не начнёт потреблять меньше памяти, поэтому они в разделе «ограничения», а не «оптимизации». Для нас основной вопрос был в том, есть ли смысл разрешать приложению потреблять 240 Мб, когда ему больше 32 не нужно. Так что речь тут речь в основном о рациональном использовании ресурсов (лимиты в cgroups можем выставить поменьше и знать точно, сколько каких контейнеров поместится в хост-машину). Ну и получить Java-ООМ приятнее, чем системный — не надо лишний раз гадать что израсходовало память (для полного счастья не хватает ExitOnFullCodeCache).
Безусловно есть, чем больше арен, тем меньше конкуренции за них при вызове malloc. Но это с точки зрения теории, на практике всё зависит от приложения. Для наших типовых сервисов сокращение числа арен до 4 не повлияло никак на их производительность. Больше мы не эксперименировали, т.к. jemalloc зашёл лучше.

Вот это внимание к деталям! Спасибо, поправил.

В принципе, того, о чём вы говорите, вполне достаточно.
Про 35 лекций я написал, чтобы уточнить ваши вычисления.
Но лекциями мы не ограничиваемся. Лекции и не главное. Это вообще не самый подходящий формат для изучения программирования)

Главное — практика, на неё у ребят в среднем уходит не меньше 10-15 часов в неделю (во второй половине обучения больше).
Лекции нам скорее нужны, чтобы подтянуть средний уровень студентов, показать в какую сторону копать, подготовить к практике.
В прошлом году у нас получилось порядка 35 лекций (во второй половине обучения остаётся одна лекция в неделю). Мы не даём теоретических знаний и не обучаем основам программирования. Эти знания пока что хорошо прививают в наших технических вузах.

Наша же программа рассчитана таким образом, чтобы вслед за знаниями получить и опыт, а именно познакомить студентов с конкретными технологиями и процессом разработки в крупной компании. Здесь больше важна не теория, а практика: примеры использования, домашние задания и, в конце концов, применение в реальном проекте.
Да, Java/Python обязательно — именно на этих языках будет вестись разработка. Максимальный возраст теоретически не ограничен, хотя подавляющее большинство поступающих, всё-таки, младше 30 лет.
К сожалению по юридическим причинам мы можем зачислять только граждан РФ.
Да, кажется в разделе "О школе" эта информация есть)
Занятия — в московском офисе HeadHunter на улице Годовикова.
Как правило, в 18-00, два раза в неделю.
Разбивка была в 4-й школе, тогда мы набирали фронтенд и Android направления. Сейчас разбивки нет, будем готовить full-stack разработчиков.
В штат обычно потом берём на позиции разработчиков / младших разработчиков

Information

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