Исходное сообщение
"Новый выпуск ZFSonLinux 0.6.3, реализации ZFS для ядра Linux..." Отправлено Аноним, 19-Июн-14 01:41
> даже сыграло дурную шутку, икнувшись в виде 12309, т.к. если это > есть смешнее баг - я его видел и относительно новых ядрах. Забавно что те кто описал баг - признают что кривая конфигурация: Answer/Solution In this case, the server had only 260 GB memory and was not properly sized for the intended workload. As buffer use increased and available memory reached near zero, although swapping was enabled (vm.swappiness = 60), once available memory became extremely low, too many processes attempted to reclaim memory simultaneously causing spinlock contention. Therefore, the normal Out-Of-Memory process killers ("OOM-killer") and/or swapping could not take place. То-есть, памяти заведомо не хватало а когда наступил душняк - все резко ломанулись, настолько что даже своп и oom-killer в обломе оказались. То что система при этом совсем виснет - это таки баг, но он провоцируется дурной конфигурацией, которой заведомо не хватало памяти для нормальной работы. > Любая FS может игнорировать. Но не игнорирует по факту. И почти все кэши ядро может в результате отобрать. Что позволяет им быть немеряного размера пока на память никто не претендует и сдуваться если память кому-то все-таки понадобилась. И как по мне - интеграция этой механики с ядром - внушает больше доверия чем то что в ZFS, живущее своей жизнью.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> даже сыграло дурную шутку, икнувшись в виде 12309, т.к. если это >> есть смешнее баг - я его видел и относительно новых ядрах. > Забавно что те кто описал баг - признают что кривая конфигурация: > [code] > Answer/Solution > In this case, the server had only 260 GB memory and was > not properly sized for the intended workload. As buffer use increased > and available memory reached near zero, although swapping was enabled (vm.swappiness > = 60), once available memory became extremely low, too many processes > attempted to reclaim memory simultaneously causing spinlock contention. Therefore, the > normal Out-Of-Memory process killers ("OOM-killer") and/or swapping could not take place. > [/code] > То-есть, памяти заведомо не хватало а когда наступил душняк - все резко > ломанулись, настолько что даже своп и oom-killer в обломе оказались. То > что система при этом совсем виснет - это таки баг, но > он провоцируется дурной конфигурацией, которой заведомо не хватало памяти для нормальной > работы. >> Любая FS может игнорировать. > Но не игнорирует по факту. И почти все кэши ядро может в > результате отобрать. Что позволяет им быть немеряного размера пока на память > никто не претендует и сдуваться если память кому-то все-таки понадобилась. И > как по мне - интеграция этой механики с ядром - внушает > больше доверия чем то что в ZFS, живущее своей жизнью.
	Введите код, изображенный на картинке: