Упс… начинаю понимать. Формально вы правы: ОС должна справедливо разделять ресурсы между процессами а процессы — адекватно реагировать на выделение/отказ в выделении. Судя по вашему первому комментарию, OS X умеет сказать процессу: «баста, памяти ты больше не получишь» а Firefox, реагирует на это тем, что прибивает вкладку решившую кушать много памяти. В моем случае тоже все правильно: Firefox'у дают память — он ее использует, и вполне возможно готов отреагировать на сообщение об исчерпании памяти. Но Linux отдает все что у него есть, и геройски погибает. Я пробовал решать эту проблему только через cgroups, возможно существуют более мягкие решения.
Занимательно, что по поводу этой же ошибки говорят в багзиле ядра (я думаю с точки зрения ОС нет особой разницы между хромом и ФФ):
This appears to be a google chrome bug in that it tries to allocate most of your memory — you might want to set vm overcommit to disallow heavy overcommit then chrome would I think be killed
т.е. сравнивая с ответом на багрекере ФФ, понимаем что разработчики ядра и разработчики приложений так и не определились кто должен следить за потреблением ресурсов?
Большое спасибо за ваши комментарии. Страница-убийца это забавно, но распределение ресурсов и особенно поведение ОС в момент их исчерпания это уже интересно.
Отчасти вы правы. Можно ограничить процесс квотами по памяти, с системой все будит хорошо — пострадает только Firefox, но мне лично кажется это не нормально когда интерпретатор считает: скрипту надо 54Gb памяти… дадим или умрем! Лично как по мне, так луше прибивать скрипт если он захотел например больше 1Gb. Только в настройках ФФ я нигде такого не нашел, может просто плохо искал?
Погуглил немного: про это уже тут писали; страдают не все, в том числе повезло пользователям OS X; был багрепорт по этому поводу, но разработчики считают что фитча, так и должно быть:
Sounds like a straightforward resource consumption issue — especially with a 64-bit build, we can keep allocating lots and lots of memory. Eventually, your OS will start complaining or having issues, but I don't think there's anything we can (or should) do.
«Файерфокс» остаётся самым стабильным браузером в мире.
Firefox 25.0.1, 3.12.2-1-ARCH, x86_64. Вот это (можно открывать, не убъет..) до сих пор убивает огнелиса и всю систему, перезагрузится можно только посредством магии SysRq. Прекрасно понимаю что это прекрасно лечится средствами ОС… но мне кажется что это проблема именно firefox'a. У chromium'a например просто отмирает вкладка…
Между прочим именно с CloudFlare тенденция замечена еще в июне: после того, как магазинчик по продаже неких веществ пользующийся CloudFlire, попадает в реестр, записи DNS меняются, и через две минуты он уже снова работает. Через месяц-два новые IP-шники снова попадают в реестр — минута и опять все работает. Надо отдать должное роскомнадзору — старые адреса из реестра тихо удаляются.
Каков смысл для роскмнадзора в данных манипуляций непонятно, но результат налицо — страдают неповинные сайты. Просто в этот раз вышло немного погромче.
Поддержу насчет цифр. Очень хочется узнать о мощностях, объемах хранилищ данных и пропускной способности магистральных каналов необходимых для решения задач «большого брата» и сравнить их с имеющимися.
Не обязательно MTU виновато. Недавно на одном форуме разгадывали загадку: есть маршрутизатор, на нем NAT; открываем один сайт из внутренней сети — открывается, открываем с другой машины из этой же внутренней сети — не открывается. Получается доступ к сайту есть только у той машины, которая открыла его первым. В результате выяснилось, что виновато поле TIMESTAMP пакета — сайт проверял его и выкидывал пакеты от машин по timestamps которых можно было судить что это машины отличные от первой. Выпиливание данного поля из пакета решило проблему.
Изначально тоже винили провайдера. Но оказалось, виноваты кривые настройки самого сайта. Причем сайт — крупный новостной портал IT-тематики.
Без дампа трафика такую загадку не разгадать, возможно поддержка повела себя немного некорректно, но вам ехать или шашечки? Как уже говорили все что они просили поймать, и так идет через них… можно было только спросить откуда и куда и снять дамп самим.
А чем переходничок за 50 — 100 р. не выход?
Занимательно, что по поводу этой же ошибки говорят в багзиле ядра (я думаю с точки зрения ОС нет особой разницы между хромом и ФФ):
т.е. сравнивая с ответом на багрекере ФФ, понимаем что разработчики ядра и разработчики приложений так и не определились кто должен следить за потреблением ресурсов?
Большое спасибо за ваши комментарии. Страница-убийца это забавно, но распределение ресурсов и особенно поведение ОС в момент их исчерпания это уже интересно.
Firefox 25.0.1, 3.12.2-1-ARCH, x86_64. Вот это (можно открывать, не убъет..) до сих пор убивает огнелиса и всю систему, перезагрузится можно только посредством магии SysRq. Прекрасно понимаю что это прекрасно лечится средствами ОС… но мне кажется что это проблема именно firefox'a. У chromium'a например просто отмирает вкладка…
Каков смысл для роскмнадзора в данных манипуляций непонятно, но результат налицо — страдают неповинные сайты. Просто в этот раз вышло немного погромче.
Изначально тоже винили провайдера. Но оказалось, виноваты кривые настройки самого сайта. Причем сайт — крупный новостной портал IT-тематики.
Без дампа трафика такую загадку не разгадать, возможно поддержка повела себя немного некорректно, но вам ехать или шашечки? Как уже говорили все что они просили поймать, и так идет через них… можно было только спросить откуда и куда и снять дамп самим.