ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / С чем едят JAVA_OPTS ?
11 сообщений из 36, страница 2 из 2
  2  все
С чем едят JAVA_OPTS ?
    #38239624
init01
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
init01
Участник
BlazkowiczSerial должен быть быстрее, в целом, но от приводит к долгим stop-the-world паузам при сборке. Если система просто процессит какие-то данные и важно время достижения конкретной цели, то ок. А если это сервер обслуживающий множество юзеров, то Serial не подходит. Так как JVM может остановить все потоки и пол минуты собирать мусор. Юзеры всё это время будут ждать ответа от сервера.

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

В общем-то, нашёл информацию, что Serial использует один поток для выполнения всех работ по сборке мусора. Лучше всего подходит для однопроцессорных машин, иногда может быть полезен и для многопроцессорных, на которых запускаются приложения с небольшими наборами данных (примерно до 100 МБ), чего недостаточно для функционирования больших, громоздких приложений.

Думаю, что надо возвращаться к Parallel, но играть с другими параметрами.
...
Рейтинг: 0 / 0
25.04.2013, 11:13:05
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38239669
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Im27thЕсли говорится о java-приложениях, то оно у нас одно и лицензия на него одна. А так-то на сервере десяток пользователей работает в других программах и скорость важна, ибо они запускают задачи, которые обрабатываются по несколько дней, поэтому и был куплен более мощный сервер, чтобы ускорить процесс обработки.
Если задачи долгоиграющие и их нужно закончить как можно раньше, то serial, должен быть все же лучше
http://stackoverflow.com/questions/9738911/javas-serial-garbage-collector-performing-far-better-than-other-garbage-collect


Im27thВ общем-то, нашёл информацию, что [i]Serial использует один поток для выполнения всех работ по сборке мусора. Лучше всего подходит для однопроцессорных машин, иногда может быть полезен и для многопроцессорных, на которых запускаются приложения с небольшими наборами данных (примерно до 100 МБ), чего недостаточно для функционирования больших, громоздких приложений.
Я даже знаю где это написано
http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
Но стоит учесть, что это "в общем случае". А "общий случай" это многопоточный web сервер расчитаный на сотни юзеров.


Im27thДумаю, что надо возвращаться к Parallel, но играть с другими параметрами.
Если у вас 4 доступных ядра, при этот крутится десяток долгоиграющих задач, то Parallel, по-моему ни к какому приросту производительнсоти не приведёт. Так как GC будет регулярно конкурировать с работающими задачами.
Кстати, есть ключи, чтобы на GC выделить отдельные ядра. Тогда они не будет конкурировать с рабочими потоками.
Вот это стоит почитать
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

Для пущей производительности системы в целом, надо смотреть GC лог и оптмизировать исходя из полученых данных. Например размеры поколеней могут хорошо помочь, если их перенастроить на нужды приложения.
...
Рейтинг: 0 / 0
25.04.2013, 11:30:45
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38240210
J.Serge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
J.Serge
Участник
Im27thНo самое главное, что видимо никакие ухищрения менять параметры в конфиг-файлах не подхватывались. Я нашёл настройки в самой программе, поменял их и всё заработало.
ВРОДЕ БЫ.



Hу вот, а говоришь
Im27th-XX:+UseSerialGC не помогло


Самое то :)
...
Рейтинг: 0 / 0
25.04.2013, 16:11:02
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38241276
init01
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
init01
Участник
J.SergeСамое то

Спасибо!
НО
Помогло, но ненадолго.
Теперь пользователи захотели запускать задачи на 30 и на 50 ядрах. Чует моё сердце, что так и до всех 160 дойдёт.

Ладно, 30 или 50 я ещё допускаю, поэтому начал проводить испытания и оказалось, что до 22 ядер всё работает с UseSerialGC прекрасно, но после 22 начинает вылетать теперь уже с другими ошибками:
WARNING: RMI TCP Accept-0: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=1720] throws
java.lang.OutOfMemoryError: unable to create new native thread

Про ServerSocket нашёл, что надо либо в hosts надо прописать имя машины - оно, конечно же, там с самого начала прописано, либо добавить
-Dcom.sun.management.jmxremote.local.only=false
Добавил.
Не помогло.

А unable to create скорее всего следствие кривого ServerSocket.

Иногда ещё другие ошибки вылетают, но они какие-то безсистемные и одноразовые.
...
Рейтинг: 0 / 0
26.04.2013, 12:24:19
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38241354
J.Serge
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
J.Serge
Участник
Было в начале:
Im27thПоставили новый сервер. CentOS 6.3. Больше 100 ядер. Но одна злостная программулина, если задаёшь ей более 4 ядер, сваливается с ошибкой:
A fatal error has been detected by the Java Runtime Environment:
java.lang.OutOfMemoryError: Cannot create GC thread. Out of system resources.
Internal Error (gcTaskThread.cpp:38), pid=122484, tid=140387071719168
Error: Cannot create GC thread. Out of system resources.
JRE version: 6.0_21-b06
Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0-b16 mixed mode linux-amd64)
...


Сейчас:
Im27th
...до 22 ядер всё работает с UseSerialGC прекрасно, но после 22 начинает вылетать теперь уже с другими ошибками:
WARNING: RMI TCP Accept-0: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=1720] throws
java.lang.OutOfMemoryError: unable to create new native thread

Про ServerSocket нашёл, что надо либо в hosts надо прописать имя машины - оно, конечно же, там с самого начала прописано, либо добавить
-Dcom.sun.management.jmxremote.local.only=false
Добавил.
Не помогло.
...


Больше ядер - больше thread'ов. Каждому нужны ресурсы - в первую очередь память.
Надо пробовать увеличивать память выделенную для JVM (+Xmx/+Xms).
Есть еще ключ +Xss - размер стека thread'а. Можно попробовать его уменьшить.
...
Рейтинг: 0 / 0
26.04.2013, 12:59:19
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38241791
init01
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
init01
Участник
J.SergeБольше ядер - больше thread'ов. Каждому нужны ресурсы - в первую очередь память.

Это я понимаю. Поэтому играюсь уже который день с этими параметрами.

J.SergeНадо пробовать увеличивать память выделенную для JVM (+Xmx/+Xms).
Есть еще ключ +Xss - размер стека thread'а. Можно попробовать его уменьшить.

Уменьшить Xss - это я попробую,
НО
меня смущает 0.0.0.0/0.0.0.0.
Почему стало именно в эту ошибку вываливаться?
Моя первая догадка была, что оно через loopback запускает потоки, а в сетевом интерфейсе какие-то ограничения на количество, поэтому после определённого числа он уже не может выдавать ресурсы и вываливается в 0.0.0.0/0.0.0.0, соответственно ничего после этого не создаётся. Но подтверждения своей догадки в интернетах не нашёл.
...
Рейтинг: 0 / 0
26.04.2013, 15:54:43
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38241802
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
0.0.0.0 никак не связан с самой ошибкой. RMI TCP сервер видать там активно создаёт потоки.
И в какой-то момент оно падает, всё потой же причине. Системное ограничение на количество процессов:
http://devgrok.blogspot.com/2012/03/resolving-outofmemoryerror-unable-to.html
RMI TCP Accept-0: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=1720] - это говорит только о том кто именно пытался создать поток и не смог. Но к самой ошибке отношения не имеет.
...
Рейтинг: 0 / 0
26.04.2013, 16:01:24
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38461543
init01
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
init01
Участник
Спасибо!
В общем-то, перелопатив кучу параметров, вроде бы всё заработало.

НО

Теперь при запуске некоторых заданий, всё начинает жутко тормозить.

Вся память забита:
_________________________________________________________________
Код: plaintext
1.
2.
3.
4.
>free
             total       used       free     shared    buffers     cached
Mem:    1058652692 1029495024   29157668          0     266828  772509584
-/+ buffers/cache:  256718612  801934080
Swap:    292420600       5392  292415208
_________________________________________________________________

CPU работает даже круче чем 146%:
_________________________________________________________________
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
>top

top - 11:26:20 up 3 days, 17:50,  3 users,  load average: 68.45, 67.76, 87.51
Tasks: 4115 total,  50 running, 4065 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us, 58.3%sy,  8.0%ni, 33.5%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  1058652692k total, 1029500700k used, 29151992k free,   266828k buffers
Swap: 292420600k total,     5392k used, 292415208k free, 772508480k cached
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                      
 21575 prouser   30  10 27.4g 2.7g  61m S 226.7  0.3   1100:19 ssexec                                                                                      
 21561 prouser   30  10 27.0g 1.9g  65m S 181.6  0.2   2747:04 ssexec                                                                                      
 21543 prouser   30  10 27.0g 1.9g  57m S 159.8  0.2   2725:31 ssexec                                                                                      
 21564 prouser   30  10 27.0g 1.9g  60m S 184.1  0.2   2740:51 ssexec                                                                                      
 21546 prouser   30  10 27.0g 1.9g  54m S 164.7  0.2   2679:33 ssexec                                                                                      
 21540 prouser   30  10 27.0g 1.9g  55m S 184.4  0.2   2689:39 ssexec                                                                                      
 21552 prouser   30  10 27.0g 1.9g  54m S 182.2  0.2   2680:43 ssexec                                                                                      
 21562 prouser   30  10 27.2g 1.9g  54m S 172.8  0.2   2654:32 ssexec                                                                                      
 21551 prouser   30  10 27.0g 1.9g  54m S 158.8  0.2   2761:32 ssexec                                                                                      
 21553 prouser   30  10 27.0g 1.9g  54m S 167.9  0.2   2684:19 ssexec                                                                                      
 21558 prouser   30  10 27.0g 1.9g  54m S 174.4  0.2   2706:38 ssexec                                                                                      
 21539 prouser   30  10 27.0g 1.9g  55m S 180.3  0.2   2689:38 ssexec                                                                                      
 21574 prouser   30  10 27.0g 1.9g  54m S 185.9  0.2   2660:47 ssexec                                                                                      
 21536 prouser   30  10 27.0g 1.9g  50m S 182.2  0.2   2690:42 ssexec                                                                                      
 21563 prouser   30  10 27.0g 1.8g  55m S 168.2  0.2   2676:29 ssexec                                                                                      
 21537 prouser   30  10 27.0g 1.8g  52m S 179.7  0.2   2679:33 ssexec                                                                                      
 21555 prouser   30  10 27.1g 1.8g  54m S 151.7  0.2   2680:48 ssexec                                                                                      
 21541 prouser   30  10 27.0g 1.8g  53m S 177.8  0.2   2680:42 ssexec                                                                                      
 21566 prouser   30  10 27.0g 1.8g  56m S 184.4  0.2   2688:12 ssexec                                                                                      
 21545 prouser   30  10 27.0g 1.8g  53m S 169.7  0.2   2667:24 ssexec                                                                                      
 21547 prouser   30  10 27.0g 1.8g  53m S 176.0  0.2   2684:58 ssexec                                                                                      
 21538 prouser   30  10 27.0g 1.8g  51m S 183.7  0.2   2657:41 ssexec                                                                                      
 21542 prouser   30  10 27.0g 1.8g  53m S 163.8  0.2   2688:28 ssexec                                                                                      
 21544 prouser   30  10 27.0g 1.8g  53m S 178.4  0.2   2674:42 ssexec                                                                                      
 21548 prouser   30  10 27.0g 1.7g  55m S 186.2  0.2   2682:37 ssexec                                                                                      
 21556 prouser   30  10 27.0g 1.7g  54m S 185.3  0.2   2665:24 ssexec                                                                                      
 21559 prouser   30  10 27.0g 1.7g  57m S 161.3  0.2   2694:59 ssexec                                                                                      
 21572 prouser   30  10 27.0g 1.7g  54m S 182.8  0.2   2681:42 ssexec                                                                                      
 21567 prouser   30  10 27.0g 1.7g  56m S 168.8  0.2   2688:44 ssexec                                                                                      
 21550 prouser   30  10 27.0g 1.6g  54m S 154.5  0.2   2690:42 ssexec                                                                                      
 21549 prouser   30  10 27.0g 1.6g  55m S 165.7  0.2   2693:28 ssexec                                                                                      
 21565 prouser   30  10 27.0g 1.6g  53m S 181.9  0.2   2671:40 ssexec                                                                                      
 21554 prouser   30  10 27.0g 1.6g  54m S 153.8  0.2   2675:23 ssexec                                                                                      
 21560 prouser   30  10 27.0g 1.6g  54m S 171.3  0.2   2685:43 ssexec
___________________________________________________________________

Но при этом, если запустить jvisualvm, то там всё довольно уныло:



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

Или я смотрю не туда?
Или смотрю туда, но не понимаю что так и должно быть?
Или, действительно, надо какие-то параметры поправить?
Xmx или ещё чего?
...
Рейтинг: 0 / 0
12.11.2013, 11:44:49
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38462906
olexande
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olexande
Гость
Не пробовали "одно и то же задание" запускать с разным кол-вом потоков?
Может дедлоки?
...
Рейтинг: 0 / 0
13.11.2013, 03:35:59
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38462907
olexande
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olexande
Гость
"отсутствие бурления" - на них похоже по симптомам.
...
Рейтинг: 0 / 0
13.11.2013, 03:37:18
| Ответить | Цитировать | Написать  
С чем едят JAVA_OPTS ?
    #38463261
init01
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
init01
Участник
olexandeНе пробовали "одно и то же задание" запускать с разным кол-вом потоков?

Да именно это первое в голову и приходит, но пользователи такие ПОЛЬЗОВАТЕЛИ, они ж умнее и занятее всех, к тому же у их одна лицензия, а им работать надо, поэтому пока приходится сторонне наблюдать и делать теоретические выводы.

Да, когда только поставил программу, было немного времени испытать этот вариант, но я взял маленький проект и, естественно, на 30 потоках он отработал быстрее, чем на 10.
Но тогда я ещё не знал ни про jconsole, ни про jvisualvm, так что графиков не видел.

olexandeМожет дедлоки?
Да вряд ли. 80 ядер с хипертрейдингом - это до 160 потоков. Столько мы им не разрешаем запускать. Ну 50, ну 100, ну совесть-то тоже надо иметь.

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

В любом случае на графике и Perm, и Old, и Eden почти пустые.
Я это вижу так:
Eden+Perm+Old+S0+S1 = примерно гигов 20 (top почему-то считает, что 27)
40-50 потоков и весь терабайт оперативки забит.
При этом используется всего-то:
Eden 160Mb + Old 315Mb + Perm 21 = даже меньше гигабайта в каждом потоке.
То есть, если уменьшить какие-то параметры вдвое-втрое, то серверу станет легче дышать.

Или я неправильно рассуждаю?
...
Рейтинг: 0 / 0
13.11.2013, 12:23:48
| Ответить | Цитировать | Написать  
11 сообщений из 36, страница 2 из 2
  2  все
Форумы / Java [игнор отключен] [закрыт для гостей] / С чем едят JAVA_OPTS ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=38239669&tid=2128214]:
 0ms
get settings:
 8ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 176ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 46ms
get tp. blocked users:
 2ms
others: 208ms
total:  472ms
созд. / загр.: 472ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]