Java ThreadPoolExecutor - достучаться до working threads

[Zorkus]

Твиттер например, и фейсбук на Ц++ наверное уже на большую половину написан.

sorry за оффтоп, по работе плотно общаюсь с SIEM (security events management) системами, которые все как один написаны на Java. так там давно уже уперлись в ограничения JVM из-за которых даже на могучем "железе" производительность аховая. Я всё жду, что будут создатели их систем с этим безобразием делать? Как-то не верится что они бросятся переписывать всё на C++

Ну определенно, проблемы бывают. А что за проблемы можно узнать поподробнее? Ограничение JVM в чем именно - по расходу памяти (например, сравните, сколько весит Java String "hello, world!" и сколько аналогичная строка в C++ если строка однобайтовая), или сколько весит Long vs. long. по управлению хипом и GC, по работе сетевого стека, по выполнению JIT-тернутого кода? Мне интересно стало. И что за железо, спарки, x86/64, что за OS?

[Flash-04]

вот тут более релевантно:
http://stackoverflow.com/questions/9104 ... t-on-linux

[Palych]

2. Ограничения JVM на кол-во сетевых соединений (для коллекторов)

Не слышал о таком. Можно подробнее?

3. Ограничения производительносьти JVM связанные с garbage collectors. Для "правил" требуется много памяти, т.к. создается дофига динамических объектов, которые кроме того имеют малое время жизни. В итоге очень забавно смотреть на график memory allocation JVM, выглядит как пила. В итоге при росте нагрузки JVM только и занимается "сборкой мусора".
У моего любимого вендора для одного коннектора эмпирическое ограничение - всего 1,000 записей в секунду, потом коннектор становится неустойчивым и "падает". Причем "падает" не приложение, а весь JVM контейнер.

Вообще-то график memory allocation JVM должен выглядить как пила.
Я конечно не знаю подробностей, но однажды воевал именно с такой проблемой. Причём успешно. Ключевые слова - generations, growth rate of old generation... есть много литературы по этому поводу.
Забавно что моя драма имела совершенно неожиданный поворот сюжета: как оказалось, память засорялась совсем не там где мы думали - наше приложение тоже создавало кучу короткоживущих объектов, но утечка памяти была внутри JBoss, который создавал кучу объектов-долгожителей. Наши объекты практически не двигали стрелку...
Наш случай конечно показывает что Java sucks, но не потому что у ней внутри Garbage Collector. А потому что java породила монстроидально сложные решения, которые используются даже для простых случаев. Всё равно что создавать мелкие частные фирмы используя Газпром в качестве платформы.

[Zorkus]

известна. там совокупность нескольких факторов (кстати предел у всех примерно одинаков):
1. ограничения SQL БД которая используется для хранения собираемых данных. Там я смотрю есть тенденция "переползать" на облегченные версии MySQL/Postgress
2. Ограничения JVM на кол-во сетевых соединений (для коллекторов)
3. Ограничения производительносьти JVM связанные с garbage collectors. Для "правил" требуется много памяти, т.к. создается дофига динамических объектов, которые кроме того имеют малое время жизни. В итоге очень забавно смотреть на график memory allocation JVM, выглядит как пила. В итоге при росте нагрузки JVM только и занимается "сборкой мусора".
У моего любимого вендора для одного коннектора эмпирическое ограничение - всего 1,000 записей в секунду, потом коннектор становится неустойчивым и "падает". Причем "падает" не приложение, а весь JVM контейнер.

А что за ограничение БД? И какая сейчас используется? У вас Java NIO используется как я понимаю, селекторы?

[Flash-04]

Ну определенно, проблемы бывают. А что за проблемы можно узнать поподробнее? Ограничение JVM в чем именно - по расходу памяти (например, сравните, сколько весит Java String "hello, world!" и сколько аналогичная строка в C++ если строка однобайтовая), или сколько весит Long vs. long. по управлению хипом и GC, по работе сетевого стека, по выполнению JIT-тернутого кода? Мне интересно стало. И что за железо, спарки, x86/64, что за OS?

В данный момент RHL-4 x64, памяти там сколько хочешь (20Gb, но для JVM выделено 6Gb).
Сервер то не особо загружен, но вендор говорит что какое железо ни ставь, выше 3000 событий в секунду их софт не осилит (а у нас в перспективе и 10,000 на него не особо трудно возложить).

[Flash-04]

А что за ограничение БД? И какая сейчас используется? У вас Java NIO используется как я понимаю, селекторы?

Oracle. ограничение простое - жрёт много
Что там у вендора в Java приложении наворочано, я без понятия. Я всего лишь юзер, хоть и software programming background

[Flash-04]

Не слышал о таком. Можно подробнее?

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

[Flash-04]

Вообще-то график memory allocation JVM должен выглядить как пила.

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

А потому что java породила монстроидально сложные решения, которые используются даже для простых случаев. Всё равно что создавать мелкие частные фирмы используя Газпром в качестве платформы.

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

[valchkou]

известна. там совокупность нескольких факторов (кстати предел у всех примерно одинаков):
1. ограничения SQL БД которая используется для хранения собираемых данных. Там я смотрю есть тенденция "переползать" на облегченные версии MySQL/Postgress
2. Ограничения JVM на кол-во сетевых соединений (для коллекторов)
3. Ограничения производительносьти JVM связанные с garbage collectors. Для "правил" требуется много памяти, т.к. создается дофига динамических объектов, которые кроме того имеют малое время жизни. В итоге очень забавно смотреть на график memory allocation JVM, выглядит как пила. В итоге при росте нагрузки JVM только и занимается "сборкой мусора".
У моего любимого вендора для одного коннектора эмпирическое ограничение - всего 1,000 записей в секунду, потом коннектор становится неустойчивым и "падает". Причем "падает" не приложение, а весь JVM контейнер.

могу ошибаться, но что то мне подсказывает что виноваты не ограничения java, а ограничения программистов

[Flash-04]

возможно. но почему падает JVM?
ещё раз подчеркну - на рынке несколько схожих продуктов, ограничения практически одинаковые. silver bullet пока нет. ждёмс
и эта, sorry за офтоп

[valchkou]

возможно. но почему падает JVM?

вот об этом и должны задуматься разработчики.
1) разобраться почему падает
2) понять, можно ли задизайнить так чтобы не падало
(например из вышесказаного: не плодить миллион мелких объектов, реюзать потоки, распаралелить на несколько jvm или перейти на другой язык)
3) накодить так чтобы не падало
такие косяки выходят из неверного дизайна, если те же дизайнеры, а язык С++ то наврядли вас это спасет.

[Palych]

Вообще-то график memory allocation JVM должен выглядить как пила.

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

Java умеет очищать память не останавливая работы. И делает это весьма эффективно.

[Интеррапт]

Вообще-то график memory allocation JVM должен выглядить как пила.

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

Java умеет очищать память не останавливая работы. И делает это весьма эффективно.

И да и нет. Даже новый G1 garbage collector иногда останавливает работу, хотя делает это реже и на более короткие интервалы, чем старые gc на тех же задачах.

[Zorkus]

возможно. но почему падает JVM?
ещё раз подчеркну - на рынке несколько схожих продуктов, ограничения практически одинаковые. silver bullet пока нет. ждёмс
и эта, sorry за офтоп

Ну так как вы знаете, JVM падает потому, что она не порождает массу легким мелких процессов, а треды внутри JVM не имеют раздельного хипа и прочее. Где нибудь OOM в одном треде и все. А если они еще и вызывают нативный код на каком-нибудь уровне через JNI - любой выход на границу массива или повисший указатель в нем, JVM падает

[Flash-04]

Вообще-то график memory allocation JVM должен выглядить как пила.

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

Java умеет очищать память не останавливая работы. И делает это весьма эффективно.

И да и нет. Даже новый G1 garbage collector иногда останавливает работу, хотя делает это реже и на более короткие интервалы, чем старые gc на тех же задачах.

Java 7?

[Zorkus]

Вообще-то график memory allocation JVM должен выглядить как пила.

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

Java умеет очищать память не останавливая работы. И делает это весьма эффективно.

И да и нет. Даже новый G1 garbage collector иногда останавливает работу, хотя делает это реже и на более короткие интервалы, чем старые gc на тех же задачах.

Java 7?

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

[Интеррапт]

И да и нет. Даже новый G1 garbage collector иногда останавливает работу, хотя делает это реже и на более короткие интервалы, чем старые gc на тех же задачах.

Java 7?

В Java 6 появилось. С каким-то из апдейтов (update 14 или 15, не помню). Правда включать нужно было явно -XX:+UseG1GC
(упс, не заметил, что Zorkus уже ответил)

[Flash-04]

ага, интересно, можно попробовать включить его принудительно.

[Alexandr]

известна. там совокупность нескольких факторов (кстати предел у всех примерно одинаков):
1. ограничения SQL БД которая используется для хранения собираемых данных. Там я смотрю есть тенденция "переползать" на облегченные версии MySQL/Postgress
2. Ограничения JVM на кол-во сетевых соединений (для коллекторов)
3. Ограничения производительносьти JVM связанные с garbage collectors. Для "правил" требуется много памяти, т.к. создается дофига динамических объектов, которые кроме того имеют малое время жизни. В итоге очень забавно смотреть на график memory allocation JVM, выглядит как пила. В итоге при росте нагрузки JVM только и занимается "сборкой мусора".
У моего любимого вендора для одного коннектора эмпирическое ограничение - всего 1,000 записей в секунду, потом коннектор становится неустойчивым и "падает". Причем "падает" не приложение, а весь JVM контейнер.

1. а в чем конкретно затык на базе?

остальные - ежели сесть на белого коня и достать меч богатырский

2. скинуть транспорт в native код
3. пулы объектов в таких случаях должны сильно помогать. Либо есть еще один класс систем, у которых поток вертится на верхушки стека, создаются много много много мелких объектов, но в концу цикла обработки они все garbage (asp.net по этой модели сделан)

[Alexandr]

2. Ограничения JVM на кол-во сетевых соединений (для коллекторов)

Извините, а это что за зверь? дайте ссыль почитать если есть

зырьте java sockets + nio

http://www.java2s.com/Code/Java/Network ... server.htm

[Flash-04]

1. а в чем конкретно затык на базе?

requests multiplier. один запрос из Java приложения порождает 5-10 запросов к БД. Только не спрашивайте меня почему, это мне говорили консультанты интегратора которые собаку съели на этом продукте.

2. скинуть транспорт в native код

о!

[Gnome]

Это понятно. Мне бы только до этого runnable добраться...

А что если использовать ThreadFactory (передать параметром в constructor ThreadPoolExecutor) и в этой Factory все Threads создавать в одной ThreadGroup?
Тогда все созданные Threds можно enumerate через ThreadGroup.
[Сам не пробовал. Если получится - дайте знать.]

[Интеррапт]

Это понятно. Мне бы только до этого runnable добраться...

А что если использовать ThreadFactory (передать параметром в constructor ThreadPoolExecutor) и в этой Factory все Threads создавать в одной ThreadGroup?
Тогда все созданные Threds можно enumerate через ThreadGroup.
[Сам не пробовал. Если получится - дайте знать.]

Я, честно говоря, вообще не понимаю, в чем смысл собственно получить доступ к списку threads, так мы от ТС этого и не добились. Ведь по большму счету, у вас может быть, например, с десяток threads в пуле и штук 100 разных Runnable's собственно с задачами, которые переодически на этом десятке thread-ов будут выполнятся. В чем тогда поинт получить ссылку на worker thread, если ты все равно не знаешь, какой в данный момент на этом thread выполняется runnable и как следствие ты с этим runnable не можешь взаимодействовать? В то время, как если иметь свой hash map, куда добавлять/удалять runntable/thread в beforeExecute/afterExecute, то ты как бы всегда знаешь активные runnable и на каком thread он выполняется. И всегда можешь послать interrupt() этому потоку (ну и это уже дело автора, корректно имплементировать runnable, для обработки interrupt).

[crypto5]

Это понятно. Мне бы только до этого runnable добраться...

А что если использовать ThreadFactory (передать параметром в constructor ThreadPoolExecutor) и в этой Factory все Threads создавать в одной ThreadGroup?
Тогда все созданные Threds можно enumerate через ThreadGroup.
[Сам не пробовал. Если получится - дайте знать.]

И всегда можешь послать interrupt() этому потоку

А есть уверенность что executorservice от этого не поломается?

[Palych]

В то время, как если иметь свой hash map, куда добавлять/удалять runntable/thread в beforeExecute/afterExecute, то ты как бы всегда знаешь активные runnable и на каком thread он выполняется. И всегда можешь послать interrupt() этому потоку (ну и это уже дело автора, корректно имплементировать runnable, для обработки interrupt).

IMHO, в этой hash map лучше хранить не runnable, а то что надобно обрабатывать/сигналить/убивать.
Так будет понятнее и безопаснее.