Gt_>>зачем ? там кто-то утверждает что OOM killer не отрабатывает и крашится вся система ? S>Ктото утверждает что своп не нужен, не подозревая, что на самом деле без свопа всё может сложиться ещё хуже. S>1. Доступной памяти меньше S>2. io для загрузки кода обратно в память
кто-то на хабре утверждает что и земля круглая. ну давай цитату в студию, обсудим, почему ты предпочитаешь читать фриков с хабра вместо пояснения вендора.
SVZ>"у меня такая же нога и она не болит..."(с)
SVZ>А тут была массовая проблема — гцц перезагружал систему на разных версиях убунты. Обновление гцц не помогало. Кто-то переходил на цланг. SVZ>Проект немаленький — полная сборка часа на 2.5-3.
я помню, выяснилось они массового на кнопку ресет нажимали.
что то серьезней есть ?
Здравствуйте, Gt_, Вы писали:
Gt_>кто-то на хабре утверждает что и земля круглая. ну давай цитату в студию, обсудим, почему ты предпочитаешь читать фриков с хабра вместо пояснения вендора.
Ты тоже из тех, которые слушают только Гуру и не думают самостоятельно?
Здравствуйте, CreatorCray, Вы писали:
S>>2. io для загрузки кода обратно в память CC>Код будет paged in из бинарника, ему своп нафиг не нужОн.
Вот именно это файловые страницы и выбросятся из памяти во время конкуренции в условиях недостаточной памяти и без свопа.
А потом будут подгружаться с диска обратно.
Я понимаю что ко мне доверия нет, я ж луноход сиречь идиот, да?
Почитай по ссылкам
Здравствуйте, Gt_, Вы писали:
Gt_>кто-то на хабре утверждает что и земля круглая. ну давай цитату в студию, обсудим, почему ты предпочитаешь читать фриков с хабра вместо пояснения вендора.
Gt_>>кто-то на хабре утверждает что и земля круглая. ну давай цитату в студию, обсудим, почему ты предпочитаешь читать фриков с хабра вместо пояснения вендора.
S>Держи оригинал статьи, раз уж тебе Гуру нужен
ну, и в чем смысл этого перфоменса ? гуру все верно разжевал
Without swap: The OOM killer is triggered more quickly as anonymous pages are locked into memory and cannot be reclaimed. We're more likely to thrash on memory, but the time between thrashing and OOMing is reduced. Depending on your application, this may be better or worse.
Здравствуйте, Gt_, Вы писали:
S>>Держи оригинал статьи, раз уж тебе Гуру нужен
Gt_>ну, и в чем смысл этого перфоменса ? гуру все верно разжевал Gt_>Without swap: The OOM killer is triggered more quickly as anonymous pages are locked into memory and cannot be reclaimed. We're more likely to thrash on memory, but the time between thrashing and OOMing is reduced. Depending on your application, this may be better or worse.
Ты тогда уж все варианты приведи а не только фигурную цитату тог что лично тебе понравилось
Без конкуренции или с малой конкуренцией за память
При наличии swap: мы можем положить в swap анонимную память, которая редко используется и нужна только в небольшой части жизненного цикла процесса. Это позволяет использовать данную память для улучшения коэффициента попаданий в кэш и других оптимизаций.
Без swap: не можем складывать в swap редко используемую анонимную память, поскольку она вынуждена храниться только в памяти. Не факт, что это сразу приведёт к проблеме, однако в некоторых рабочих нагрузках производительность может упасть из-за устаревших анонимных страниц, забирающих место у более важных задач.
С умеренной или высокой конкуренцией за память
При наличии swap: у всех типов памяти одинаковая вероятность высвобождения. Это означает большую вероятность успешного высвобождения страниц — мы можем высвобождать страницы, которые не будут быстро снова приводить к отказу (к пробуксовке [thrashing]).
Без swap: анонимные страницы ограничены памятью, т.к. не имеют альтернатив для хранения. Вероятность успешного долгосрочного высвобождения страниц ниже, поскольку оно доступно только для некоторых типов памяти. Риск пробуксовки страниц выше. Случайный читатель может подумать, что так всё равно будет лучше, поскольку не случится нагрузки на ввод/вывод диска, но это не так: мы попросту переносим disk I/O из-за swapping'а на сброс горячего страничного кэша и сегментов кода, которые нам скоро понадобятся.
При временных всплесках в потреблении памяти
При наличии swap: устойчивость к временным всплескам выше, однако в случае резкой нехватки памяти время между пробуксовкой и работой OOM killer может вырасти. Нам лучше видны причины нагрузки на память и мы можем более рационально повлиять на них, можем осуществить контролируемое вмешательство.
Без swap: OOM killer вызывается быстрее, поскольку анонимные страницы ограничены памятью и не могут быть высвобождены. Мы скорее столкнёмся с пробуксовкой, однако время между ней и OOMing'ом сократится. Будет лучше или хуже — зависит от конкретного приложения. Например, основанное на очередях приложение может захотеть потребовать такого быстрого перехода от пробуксовки к OOMing'у. Тем не менее, всё равно уже слишком поздно для полезных действий — OOM killer вызывается только в случаях резкой нехватки памяти. Вместо того, чтобы полагаться на такое поведение, в первую очередь лучше позаботиться о более оппортунистическом подходе (т.е. направленном на следование своим интересам — прим. перев.) к убиванию процессов при достижении состояния конкуренции за память.
Здравствуйте, Gt_, Вы писали:
S>>Ты тогда уж все варианты приведи а не только фигурную цитату тог что лично тебе понравилось Gt_>мне не понравилось то что ты полез с советами не подозревая, что есть целый ряд ситуаций, где отсутствие свопа оправдано.
Например? Опиши свою.
S>>>Ты тогда уж все варианты приведи а не только фигурную цитату тог что лично тебе понравилось Gt_>>мне не понравилось то что ты полез с советами не подозревая, что есть целый ряд ситуаций, где отсутствие свопа оправдано. S>Например? Опиши свою.
S>>>>Ты тогда уж все варианты приведи а не только фигурную цитату тог что лично тебе понравилось Gt_>>>мне не понравилось то что ты полез с советами не подозревая, что есть целый ряд ситуаций, где отсутствие свопа оправдано. S>>Например? Опиши свою. Gt_>я уже объяснял, из-за zookeeper
У него про swap другое написано:
Set the Java heap size. This is very important to avoid swapping, which will seriously degrade ZooKeeper performance. To determine the correct value, use load tests, and make sure you are well below the usage limit that would cause you to swap. Be conservative — use a maximum heap size of 3GB for a 4GB machine.
...
Do not put ZooKeeper in a situation that can cause a swap. In order for ZooKeeper to function with any sort of timeliness, it simply cannot be allowed to swap. Therefore, make certain that the maximum heap size given to ZooKeeper is not bigger than the amount of real memory available to ZooKeeper. For more on this, see Things to Avoid below.
...
You should take special care to set your Java max heap size correctly. In particular, you should not create a situation in which ZooKeeper swaps to disk. The disk is death to ZooKeeper. Everything is ordered, so if processing one request swaps the disk, all other queued requests will probably do the same. the disk. DON'T SWAP.
Be conservative in your estimates: if you have 4G of RAM, do not set the Java max heap size to 6G or even 4G. For example, it is more likely you would use a 3G heap for a 4G machine, as the operating system and the cache also need memory. The best and only recommend practice for estimating the heap size your system needs is to run load tests, and then make sure you are well below the usage limit that would cause the system to swap.
Там нет рекомендация отключать своп. Напротив, там рекомендации подтюнить размер кучи
серьезно, ты втирал что "У него про swap другое написано"
теперь ссылаешься на админку зукипера в вакуме, где никто посторонний ему не мешает. иди смотри рекомендации по хадупу. работай, раз уж полез с поучениями.
Здравствуйте, Sheridan, Вы писали:
4>>Сравнивать работу с текстом в FAR-е и блокноте было очень показательно. Успехов. S>Говорить что анализ логов в far лучше, чем cat/grep/tail — довольно опрометчиво. Впрочем, что это я про "сравнивать"? Нет тут никакого сравнения. Чтобы сравнивать надо хоть какое-то время пользоваться и тем и другим...
S>Карма у тебя такая. OOM-killer приходит к приложению своеобразным путём. Я много такого ловил, особенно на серверах под управлением особо умных админов.
Само существование OOM killer-а прекрасно показывает уровень архитектуры в линуксах.
Прикинь, в винде нету OOM killer-а. Там просто malloc возвращает нуль, если нету памяти ни в свопе ни в раме. И выделяющий память может чтото адекватное сделать, если ее вдруг не оказалось, а не тупо инициировать общесистемную эвристическую децимацию. Более того, всякие AppVerifier'ы умеют эмулировать нехватку памяти для отдельного приложения, и девелоперы имею реальную возможность такую ситуацию протестить и сделать так, чтоб ничего не падало.
Удивительно, что можно было сделать без костылей.
Да, ты можешь сказать что надо отключить overcommit, и будет хорошо. Но... тамошные быдлокодеры привыкли к overcommit да и вообще архитектура такая, что ей это надо, потому хорошо не будет
Тут пожалуй стоит добавить про странные стратегии аллокации памяти под кэши в линуксе. Такое ощущение что все это работает параллельно и монопенисуалистически относительно текущего положения дел. В результате в линуксе после активного IO память может оказаться занята файловым кэшем настолько, что последующая аллокация зафэйлится и соответственно разбушуется ООМ киллер. В ситуации когда свободной памяти мало, изза того что она вся занята кэшами, поведение ООМ киллера адекватностью не отличается.
В винде аллокация не фэйлится, а ждет освобождения (возможно со сбросом на диск) буферов. Память, занятая под файловые кэши и под подмапленные немодифицированные страницы файлов (кстати, это та же самая память), занятой не считается и никак там не ограничивает обычные аллокации.
Как много веселых ребят, и все делают велосипед...
Gt_>>>там нету такого S>>Серьёзно?? Gt_>серьезно, ты втирал что "У него про swap другое написано" Gt_>теперь ссылаешься на админку зукипера в вакуме, где никто посторонний ему не мешает. иди смотри рекомендации по хадупу. работай, раз уж полез с поучениями. Оттуда
3. Increase ZooKeeper's heap memory size so that it does not swap:
hadoop$ vi $ZK_HOME/conf/java.env
export JAVA_OPTS="-Xms1000m -Xmx1000m"
4. Increase ZooKeeper's maximum client connection number to handle more concurrent requests:
hadoop$ echo "maxClientCnxns=60" >> $ZK_HOME/conf/zoo.cfg
5. Increase HBase's heap memory size to run HBase smoothly:
hadoop$ vi $HBASE_HOME/conf/hbase-env.sh
export HBASE_HEAPSIZE=8000
...
Steps 3 and 4 are about ZooKeeper settings. ZooKeeper is very sensitive to swapping, which will seriously degrade its performance. ZooKeeper's heap size is set in the java.env file. ZooKeeper has an upper bound on the number of connections it will serve at any one time. Its default is 10, which is too low for HBase, especially when running MapReduce on it. We would suggest setting it to 60.
In step 5, we configured HBase's heap memory size. HBase ships with a heap size of 1 GB, which is too low for modern machines. A reasonable value for large machines is 8 GB or larger, but under 16 GB.
Опять ни слова про отключение swap, что ж ты делать то будеш...
S>Опять ни слова про отключение swap, что ж ты делать то будеш...
я пришел сюда учить, так что продолжим. ищи дальше, тут снова блохер не учитывает что zookeeper лишь один из сервисов и какой хип ему не выставь, память под ноль выжрать может сосед.
давай, не ленись, уже скоро ты поймешь что имел ввиду гуру фразй "Depending on your application, this may be better"
