Здравствуйте, Cyberax, Вы писали:
C>Тут хороший принцип есть — лучше позволить системе упасть, а потом правильно восстановиться после сбоя, чем при состоянии сбоя пытаться его маскировать.
+1, вобщем-то. Странно, что так долго никто не озвучивал эту наиболее важную сторону проблемы.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Cyberax, Вы писали:
C>>Тут хороший принцип есть — лучше позволить системе упасть, а потом правильно восстановиться после сбоя, чем при состоянии сбоя пытаться его маскировать. R>+1, вобщем-то. Странно, что так долго никто не озвучивал эту наиболее важную сторону проблемы.
ну да. Когда микрософт ворд падает а потом правильно восстанавливается после сбоя это нормально, он же документ восстанавливает и редактирование не теряется.
if the JVM is spending more than 98% of the total time doing garbage collection and is recovering less than 2% of the heap, it will throw an out-of-memory expection
Если приложение блокировано 5 мин потом работает 30 сек, то оно работает 10%. А с точки зрения пользователей оно вовсе не работает. Плюс, с одной сборки мусора такую ситуацию определить нельзя. Нужно, как минимум 2.
В добавок интересна взаимосвязь этой опции с CMS. Когда запускается полная сборка мусора в CMS, то это какой сборщик?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Если приложение блокировано 5 мин потом работает 30 сек, то оно работает 10%. А с точки зрения пользователей оно вовсе не работает. Плюс, с одной сборки мусора такую ситуацию определить нельзя. Нужно, как минимум 2.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Если приложение блокировано 5 мин потом работает 30 сек, то оно работает 10%. А с точки зрения пользователей оно вовсе не работает. Плюс, с одной сборки мусора такую ситуацию определить нельзя. Нужно, как минимум 2.
Этот процент можно крутить, я точно помню.
ANS>В добавок интересна взаимосвязь этой опции с CMS. Когда запускается полная сборка мусора в CMS, то это какой сборщик?
AFAIR, если ты запускаешь полную сборку — то это уже не CMS. Для CMS там свои опции.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
C>>AFAIR, если ты запускаешь полную сборку — то это уже не CMS. Для CMS там свои опции. ANS>Она сама запускается — concurrent mode failure и вперёд.
Это я и имел в виду. Если запускается stop-the-world, то CMS уже сделал всё возможное.
Что значит "маскировать сбой"? Если мы пытаемся ловить OutOfMemoryError, который наследует не Exception а Error, мы уже частично маскируем проблему, подменяя обычную работу вирт. машины (которая просто закроет процесс, когда это Error дойдет до верхнего метода и не будет обработан).
Если позволить системе системе упасть — то ... что же запускать еще один процесс который мониторит не упал ли наш, и если упал — запустить его снова?
Здравствуйте, leokom, Вы писали:
L>Что значит "маскировать сбой"? Если мы пытаемся ловить OutOfMemoryError, который наследует не Exception а Error, мы уже частично маскируем проблему, подменяя обычную работу вирт. машины (которая просто закроет процесс, когда это Error дойдет до верхнего метода и не будет обработан).
Ну, при OOM процесс (т.е. VM) не завершается.
L>Если позволить системе системе упасть — то ... что же запускать еще один процесс который мониторит не упал ли наш, и если упал — запустить его снова?
Мне кажется, что здесь важно понимать, что подобные исключения (включая NPE, IAE, ...) это симптомы ошибок, но не сами ошибки. И правильной стратегией было бы выяснить причину (при помощи отладчика, профайлера, логов...) и исправить ее (изменить код, возможно конфигурацию и т.п.). А попытка остаться на плаву любой ценой, неважно как: явно перехватив исключение, якобы обработав его; или периодически перезапуская постоянно падающий процесс отдельным скриптом; — на мой взгляд это все равно, что лечить кашель пластырем на рот.
Здравствуйте, dshe, Вы писали:
D>Ну, при OOM процесс (т.е. VM) не завершается.
Стоп... Я начал сейчас сомневаться в понимании Core Java. Если объект который наследует Throwable не будет перехвачен никем, то насколько я понимаю процесс завершится.
main() {
//smth
throw new OutOfMemoryError(); //- этот иксепшн мог быть сгенерен виртуальной машиной
//anything
}
Тут anything выполнен не будет и ВМ завершит джава-программу и себя. Или я не прав?
Здравствуйте, leokom, Вы писали:
L>Здравствуйте, dshe, Вы писали:
D>>Ну, при OOM процесс (т.е. VM) не завершается.
L>Стоп... Я начал сейчас сомневаться в понимании Core Java. Если объект который наследует Throwable не будет перехвачен никем, то насколько я понимаю процесс завершится.
L>main() {
L>//smth L>throw new OutOfMemoryError(); //- этот иксепшн мог быть сгенерен виртуальной машиной L>//anything L>}
L>Тут anything выполнен не будет и ВМ завершит джава-программу и себя. Или я не прав?
Завершится поток, в котором вылетело необработанное исключение. В твоем примере поток один ==> когда он завершится, весь процесс завершится.
Здравствуйте, leokom, Вы писали:
L>Что значит "маскировать сбой"?
Пытаться игнорировать исключение, без должных мер по предотвращению его причин.
L>Если мы пытаемся ловить OutOfMemoryError, который наследует не Exception а Error, мы уже частично маскируем проблему, подменяя обычную работу вирт. машины (которая просто закроет процесс, когда это Error дойдет до верхнего метода и не будет обработан).
Нет, уже ответили.
L>Если позволить системе системе упасть — то ... что же запускать еще один процесс который мониторит не упал ли наш, и если упал — запустить его снова?
От одного OOM оно не умрёт...
Подоход "перезапустить при падении" — это тоже вариант. Надо только при этом писать так, чтобы восстановление после падения не вызывало других ошибок.
L>Видимо это "решение" действительно не будет работать так как вирт. машина перед броском этого иксепшна сама попыталась "собрать мусор"... Вопрос в том имеет ли смысл ловить такой иксепшн и например пытаться ручками за-null-ить какие-то возможно ненужные объекты, а потом "попросить" вирт. машину снова "поубирать" (только попросить так как гарантий выполнения сборщика она не дает). Или после OutOfMemory работа вирт. машины вообще неопределенна, и лучше всего закрыть аппликейшн?
Если есть потенциально ненужные объекты(причем или много, или крупные по размеру, то есть те, которые действительно занимают значительную область памяти), то не лучше ли ссылаться на них через мягкие ссылки? В таком случае не будет ни OOM, ни геморроя с его отловом.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
DZ>>Спецификация гарантирует, что перед тем, как бросить out of memory, jvm сделает все возможное для того, чтобы попытаться очистить память (запустит full collection, соберет soft references). B>Есть мнение, что при определенных настройках (Parallel GC?) и очень быстром заполнении памяти, можно вызвать OEM ещё до того как GC успеет освободить память, остановить все потоки, или увеличить хип. Сам не сталкивался, всё никак нет времени опробовать.
На 1.3 с таким сталкивались. В последних версиях — не знаю.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, leokom, Вы писали:
L>Задача — получение данных из внешнего хранилища (веб-сервис), конвертация в формат базы и сохранение. Прога многопоточная, количество потоков заранее не детерминировано — по одному потоку на данные одной организации зарегистрированной в веб-сервисе, а количество организаций не фиксированное. L>Веб-сервис тупой — присылает данные большими потоками (десятки метров), пейджинг у него не реализован (то есть отфильтровать по дате или как-то еще не получится). L>Много потоков * много памяти на каждый поток --> OutOfMemory (не постоянно ... но случается)
А данные какого рода? Возможны 2 варианта:
1. сервер выдает длинный список данных, каждый элемент которого является законченным(не зависящим от других) объектом, и его можно положить в базу
2. все десятки мегабайт — один объект, который нужно обрабатывать целиком
Второй вариант сильно сложнее, и общего решения для него нет, но встречается такое реже.
А в случае первого — выкидываем DOM, берем SAX. Вычитываем понемногу данные из потока. Как только понимаем, что приняли законченный объект, кидаем его в базу, и забываем, переходя к считыванию дальше. Если такие атомарные объекты невелики, то OOM словить будет сложно.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, leokom, Вы писали:
L>Задача — получение данных из внешнего хранилища (веб-сервис), конвертация в формат базы и сохранение. Прога многопоточная, количество потоков заранее не детерминировано — по одному потоку на данные одной организации зарегистрированной в веб-сервисе, а количество организаций не фиксированное. L>Веб-сервис тупой — присылает данные большими потоками (десятки метров), пейджинг у него не реализован (то есть отфильтровать по дате или как-то еще не получится). L>Много потоков * много памяти на каждый поток --> OutOfMemory (не постоянно ... но случается)
