История изменений
Исправление ZenitharChampion, (текущая версия) :
Это тот чел, который говорит «аппаратное ускорение видео в формате h264 в браузере под Linux не работает». Ему показываешь, что работает, он «то, что у тебя одного работает, не значит что у всех работает. А так вообще есть зоопарк железа, и у остальных - не работает».
И вот он снова высказывается в духе «в Linux всё плохо, надо в два раза больше памяти, чем в винде. А кто не согласен, фанатик и арчешкольник. Аргументацию я приводить не буду, потому что ты всё равно не поймёшь. Твою аргументацию я тоже читать не буду, потому что я там не прочитаю ничего для себя нового». Со мной он как-то более вежлив был, когда убеждал, что Linux - хуже, чем Windows.
По поводу количества оперативной памяти, могу выдать следующие наблюдения. В 2012 году у меня было 2 Гб ОЗУ, я запускал виртуальную машину, выделяя для неё с 512 Мб ОЗУ. Я также пытался выделить гигабайт, ведь остальная система занимала только 200 Мб. Вместе с виртуалкой всё бы заняло 1200 Мб, ещё 800 осталось бы. Но как только количество занятой ОЗУ преодолевало значение 60%, система начинала жутко своппиться, и виртуальная машина больше не могла работать.
Помог ключик «vm.swappiness = 10». С этим параметром, система начинала своппиться только тогда, когда оперативной памяти осталось только 10%. А по умолчанию она начинала своппиться, когда оставалось 40%.
Кроме того, на этой системе наблюдалась следующая проблема. Я играл в Minecraft при помощи Java 1.6. Когда игра стала требовать Java 1.8, она отказывалась запускаться со странной ошибкой. Оказалось, проблема в лимитах.
ulimit -a
core file size (blocks, -c) 1
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 15933
max locked memory (kbytes, -l) 128
max memory size (kbytes, -m) 1745900
open files (-n) 2048
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 15933
virtual memory (kbytes, -v) 2703200
file locks (-x) unlimited
Специалисты на ЛОРе заметили, что у меня параметр virtual memory - низкий. Я переопределил значение, выполнив ulimit -v 5406400 (в два раза больше, чем было), и игра заработала, как ни в чём ни бывало. Также исчезли щелчки звука в Dosbox при использовании хардварного миди Emu10k, и краши браузера в рандомные моменты (особенно при работе с большими данными).
Проблема проявляется только в openSUSE (я использую 64-бит версию) и только на 2 Гб ОЗУ. При использовании 4 Гб ОЗУ, значение virtual memory встаёт правильным. Также на Debian значение является правильным. Возможно, даже до сих пор не поправили (описанное мной актуально на SLES 11 SP4 и openSUSE 11.4), и если это так, что пользователи, при наступлении этой проблемы, ставят побольше ОЗУ.
Чтобы не прописывать это перед запуском игры, я зашёл в Yast => Редактирование параметров /etc/sysconfig, и зашёл в раздел System => Limits => SOFTVIRTUALLIMITS. Умолчальное значение 80. Я так и не понял, как коррелирует значение из «ulimit -a» и значение из YAST, ну увеличил до 90, проблемы исчезли.
А теперь я узнал ещё и про какое-то «vm.overcommit». Ещё и с хорошим описанием, специально для тех, кто об этом параметре только сейчас услышал.
Исправление ZenitharChampion, :
Это тот чел, который говорит «аппаратное ускорение видео в формате h264 в браузере под Linux не работает». Ему показываешь, что работает, он «то, что у тебя одного работает, не значит что у всех работает. А так вообще есть зоопарк железа, и у остальных - не работает».
И вот он снова высказывается в духе «в Linux всё плохо, надо в два раза больше памяти, чем в винде. А кто не согласен, фанатик и арчешкольник. Аргументацию я приводить не буду, потому что ты всё равно не поймёшь. Твою аргументацию я тоже читать не буду, потому что я там не прочитаю ничего для себя нового». Со мной он как-то более вежлив был, когда убеждал, что Linux - хуже, чем Windows.
По поводу количества оперативной памяти, могу выдать следующие наблюдения. В 2012 году у меня было 2 Гб ОЗУ, я запускал виртуальную машину, выделяя для неё с 512 Мб ОЗУ. Я также пытался выделить гигабайт, ведь остальная система занимала только 200 Мб. Вместе с виртуалкой всё бы заняло 1200 Мб, ещё 800 осталось бы. Но как только количество занятой ОЗУ преодолевало значение 60%, система начинала жутко своппиться, и виртуальная машина больше не могла работать.
Помог ключик «vm.swappiness = 10». С этим параметром, система начинала своппиться только тогда, когда оперативной памяти осталось только 10%. А по умолчанию она начинала своппиться, когда оставалось 40%.
Кроме того, на этой системе наблюдалась следующая проблема. Я играл в Minecraft при помощи Java 1.6. Когда игра стала требовать Java 1.8, она отказывалась запускаться со странной ошибкой. Оказалось, проблема в лимитах.
ulimit -a
core file size (blocks, -c) 1
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 15933
max locked memory (kbytes, -l) 128
max memory size (kbytes, -m) 1745900
open files (-n) 2048
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 15933
virtual memory (kbytes, -v) 2703200
file locks (-x) unlimited
Специалисты на ЛОРе заметили, что у меня параметр virtual memory - низкий. Я переопределил значение, выполнив ulimit -v 5406400 (в два раза больше, чем было), и игра заработала, как ни в чём ни бывало. Также исчезли щелчки звука в Dosbox при использовании хардварного миди Emu10k, и краши браузера в рандомные моменты (особенно при работе с большими данными).
Проблема проявляется только в openSUSE (я использую 64-бит версию) и только на 2 Гб ОЗУ. При использовании 4 Гб ОЗУ, значение virtual memory встаёт правильным. Также на Debian значение является правильным. Возможно, даже до сих пор не поправили (описанное мной актуально на SLES 11 SP4 и openSUSE 11.4), а также что пользователи, при наступлении этой проблемы, ставят побольше ОЗУ.
Чтобы не прописывать это перед запуском игры, я зашёл в Yast => Редактирование параметров /etc/sysconfig, и зашёл в раздел System => Limits => SOFTVIRTUALLIMITS. Умолчальное значение 80. Я так и не понял, как коррелирует значение из «ulimit -a» и значение из YAST, ну увеличил до 90, проблемы исчезли.
А теперь я узнал ещё и про какое-то «vm.overcommit». Ещё и с хорошим описанием, специально для тех, кто об этом параметре только сейчас услышал.
Исходная версия ZenitharChampion, :
Это тот чел, который говорит «аппаратное ускорение видео в формате h264 в браузере под Linux не работает». Ему показываешь, что работает, он «то, что у тебя одного работает, не значит что у всех работает. А так вообще есть зоопарк железа, и у остальных - не работает».
И вот он снова высказывается в духе «в Linux всё плохо, надо в два раза больше памяти, чем в винде. А кто не согласен, фанатик и арчешкольник. Аргументацию я приводить не буду, потому что ты всё равно не поймёшь. Твою аргументацию я тоже читать не буду, потому что я там не прочитаю ничего для себя нового». Со мной он как-то более вежлив был, когда убеждал, что Linux - хуже, чем Windows.
По поводу количества оперативной памяти, могу выдать следующие наблюдения. В 2012 году у меня было 2 Гб ОЗУ, я запускал виртуальную машину, выделяя для неё с 512 Мб ОЗУ. Я также пытался выделить гигабайт, ведь остальная система занимала только 200 Мб. Вместе с виртуалкой всё бы заняло 1200 Мб, ещё 800 осталось бы. Но как только количество занятой ОЗУ преодолевало значение 60%, система начинала жутко своппиться, и виртуальная машина больше не могла работать.
Помог ключик «vm.swappiness = 10». С этим параметром, система начинала своппиться только тогда, когда оперативной памяти осталось только 10%. А по умолчанию она начинала своппиться, когда оставалось 40%.
Кроме того, на этой системе наблюдалась следующая проблема. Я играл в Minecraft при помощи Java 1.6. Когда игра стала требовать Java 1.8, она отказывалась запускаться со странной ошибкой. Оказалось, проблема в лимитах.
ulimit -a
core file size (blocks, -c) 1
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 15933
max locked memory (kbytes, -l) 128
max memory size (kbytes, -m) 1745900
open files (-n) 2048
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 15933
virtual memory (kbytes, -v) 2703200
file locks (-x) unlimited
Специалисты на ЛОРе заметили, что у меня параметр virtual memory - низкий. Я переопределил значение, выполнив ulimit -v 5406400 (в два раза больше, чем было), и игра заработала, как ни в чём ни бывало. Также исчезли щелчки звука в Dosbox при использовании хардварного миди Emu10k, и краши браузера в рандомные моменты (особенно при работе с большими данными).
Проблема проявляется только в openSUSE (я использую 64-бит версию) и только на 2 Гб ОЗУ. При использовании 4 Гб ОЗУ, значение virtual memory встаёт правильным. Также на Debian значение является правильным. Возможно, даже до сих пор не поправили, а пользователи, при наступлении этой проблемы, ставят побольше ОЗУ.
Чтобы не прописывать это перед запуском игры, я зашёл в Yast => Редактирование параметров /etc/sysconfig, и зашёл в раздел System => Limits => SOFTVIRTUALLIMITS. Умолчальное значение 80. Я так и не понял, как коррелирует значение из «ulimit -a» и значение из YAST, ну увеличил до 90, проблемы исчезли.
А теперь я узнал ещё и про какое-то «vm.overcommit». Ещё и с хорошим описанием, специально для тех, кто об этом параметре только сейчас услышал.