Вопрос к девелоперам

Апдейт по теме:

Старший девелопер поковырялся в коде. Сказал что там есть пара косяков которые писали пара сабжей с альтернативной одаренностью. Он будет ковырять тему джава профайлером и фиксить.

Так же, некая трабла еще в том что Томкат 8 и mTLS шифрование дружат так себе. А здесь каждый запрос должен быть очень качественно зашифрован, плюс все это бегает по OCSP, который, судя по всему, реализован здесь довольно перанально. Хотя, из моего изучения сабжа, мне кажется что OCSP вообще не имеет нормальной реализации нигде. Протокол который только в задумке работает хорошо, но никаких стандартов там особо нет.

Тут два момента:
1) Способности железа: вот у меня на столе лежит копеечная железка с ARM'овским недопроцессором, типа тех что используются в мобильных телефонах. Одно ядро этой железки генерирует три гигабайта данных в секунду (!).
2) Концептуально-идеологический момент: прозвучало слово Джава.
Я помню, когда-то давно, когда Джава только появилась, на какой-то конфе в ответ на реплику маркетолога, что дескать джава как концепция спроектирована так чтобы в ней можно было всё и никому за это ничего не было, какой-то чувак ехидно спросил - что, и на нуль делить тоже можно? - и получил ответ - Да, можно.
Джава, как идеология, делит экосистему на две части - вменяемое ядро, в котором умные люди должны правильно расставить обработчики исключений. И дикий юзерспейс, в котором резвятся всякие одноклеточные кодеры-Брахмапутры. Так построен в частности SAP. Стандартным для юзерспейса Джавы является, например, перебор строк многомегабайтной базы данных с делением одной ячейки на другую и переходу к выбору следующей строки по ексцепшену деления на ноль. Понятно, что на такой подход процессорного времени и памяти не напасёшься. И это уже бизнесу решать, на что ему тратить деньги - на железо или на вменяемых людей. Как показывает практика - бизнес предпочитает платить за железо. Главное - Джава даёт бизнесу возможность выбора и бизнесу это нравится.

Взгляд со стороны манагера по продукту и по проектам, а также аналитика:
1. Инфы мало, но уже ясно, что архитектура продумана через Ж. О статистике нагрузки и масштабировании не подумано от слова "совсем". (подозреваю что и запасного решения не задумано на случай если основной сервис ляжет)
2. Если где-то просто была ошибка - уже после первого звоночка о нехватке начально запланированных ресурсов это поделие должно было сразу быть отправлено назад архитектору/аналитикам/девелоперам на проверку и возможную переработку
3. Раз было позволено просто тупо докинуть ресурсов - то п.2 либо не был сделан, либо принято волевое решение "насрать" на эффективность системы и просто наращивать хардвер. (нынче очень популярный способ решения всех проблем. Поэтому и простейший калькулятор нынче тянет 3 гига зависимостей и 25 библиотек и требует 2-корного проца и 4 Ги памяти: типа железо ничего не стоит, а программисты дороги. :))

Взгляд со стороны админа:
1) инфы явно мало;
2) юзать nmon с анализатором и экспортом в эксель - для получения тонн наглядной фактуры по профилю нагрузки, блокировках и т.п. - при этом сам nmon практически не дает нагрузки на систему, идет у меня как объективное ср-во контроля при проведении нагрузочных тестов;
3) dtrace/strace;
4) что-то нативное джавовское для профилирования и получения статы по ботлнекам в джаве.

Да. Еще. Если уж ты знаешь на кого я работаю (еще бы ты, из всех, не знал) - клиентов, в общем смысле, 8 лямов. Но это суммарно. Не одновременных коннектов, конечно, а просто констатация: "У этого банка 8 000 000 клиентов".

Вообще, именно с этой аппликацией история интересная. Я был совсем зеленым и это было одним из моих первых заданий - создать среду разработки для этой аппликации. Спросил девелопера в каком углу делать. Он указал угол. Спустя три месяца, я напрямую этого дева (контрактника) в глаза, назвал мудоёбом. Потому что он попросил создать среду в том углу который является аналогом shared hosting где единый конфиг на томкат, единый конфиг на диски и вообще на все. А выяснилось что для аппликации все нужно очень индивидуально свое. Я утрахался в сопли с if, then, else и прочими ||.

Тем не менее, у меня сейчас, почему-то, стойкое ощущение что дай я им с 4-х ядер до 6-ти - толку будет ноль и они попросят 8. Я прав в своих догадках? Мне просто любопытно - насколько может кривой код положить железо?

Ну давай по порядку.

Зная, на кого ты трудишься, я оцениваю пиковое количество клиентских запросов на логирование где-то в 10,000-20,000 в минуту (это явно завышенный, почти невозможный результат). Если это раскидать на 6 хостов, мы имеем в пике 3333 запроса в минуту, или около 55 запросов в секунду на хост, или 13 запросов в секунду на ядро. Много это или мало? По моему опыту работы в телекоммуникациях, 1 (ОДИН) четырехпроцессорный хост влегкую обрабатывал около сотни запросов в секунду, при этом что эти запросы, на секундочку, были критичны по времени (ISDN-плата не будет ждать больше строго оговоренного времени, причем весьма небольшого, на изменение статуса звонка). Причем это была система под Виндой, а не под чем-то типа Мандрейка или QNX.

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

Есть вариант (я не знаю, сколько ты памяти выделяешь на хост), что мало памяти, и там своп недетский происходит постоянно, например. Ты имеешь картинку нагруженности хостов (память, процессор, диск, сетевые запросы), которые ты им выделяешь?

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

Мне приходилось работать с системой, где было 250,000,000 (двести пятьдесят миллионов) запросов за 12 часов, причем это был трейдинг, т.е. время выполнения было крайне критичным, поэтому мне представляется, что я знаю, о чем говорю.