Нашёл любопытную статью на Хабре про оптимизацию серверов "одноглазников.ру":
http://habrahabr.ru/company/odnoklassniki/blog/266005
Выдержка:
"Дефрагментация запускается только тогда, когда свободная память опускается ниже
определённой отметки (zone watermark), и в нашем случае это происходило
28 сентября 2015 г., 10:22 пользователь "Артём Н."
написал:
> Нашёл любопытную статью на Хабре про оптимизацию серверов
> "одноглазников.ру":
> http://habrahabr.ru/company/odnoklassniki/blog/266005
>
> Выдержка:
> "Дефрагментация запускается только тогда, когда свободная
Странный совет - в случае когда приложение попытается аллоцировать памяти с
залезанием в зону min_free_kbytes, то придет злобный oom-killer и накажет кого
попало.
Стоит заметить, что у них 45 Гб оперативки и, в основном, как я понимаю, всё
тратится на кэш в виде tmpfs.
Приложение же вероятно
Артём Н. artio...@yandex.ru wrote:
On 03.08.2015 00:08, Илья wrote:
я думаю это ругается /usr/lib/pm-utils/pm-functions:
При выборе режима сна? С чего бы?
[]
Нужно смотреть на момент когда возникает ошибка или зависание
/var/log/kern.log. Там все есть.
Ошибки пока не было, но
а /sys на момент попытки записи в него еще смонтирован?
2015-215 09:24 Илья mir...@yandex.ru wrote:
Пн. авг. 3 00:17:38 MSK 2015: performing hibernate
test0
test1
sh: echo: I/O error sudo mcedit /usr/lib/pm-utils/pm-functions: echo -n
disk /sys/power/state
--
To UNSUBSCRIBE, email
Обновил BIOS, перезагрузился.
Aug 3 19:01:12 dana kernel: [202669.523214] PM: Allocated 11 049 008 kbytes in 69.98 seconds
(157.88 MB/s) === просто фантастическая скорость ;)
Например, у меня как то так
grep 'PM: Allocated' /var/log/kern.log
Allocated 2 378 652 kbytes in 0.29 seconds
On 04.08.2015 10:43, dimas wrote:
а /sys на момент попытки записи в него еще смонтирован?
Не знаю, не проверял. Но могу предположить, что да, т.к. системный (не самописный) обработчик pm-utils пытается туда что-то писать
в это время.
2015-215 09:24 Илья mir...@yandex.ru wrote:
Пн. авг. 3
On 04.08.2015 14:00, Andrey Melnikoff wrote:
Артём Н. artio...@yandex.ru wrote:
On 03.08.2015 00:08, Илья wrote:
я думаю это ругается /usr/lib/pm-utils/pm-functions:
При выборе режима сна? С чего бы?
[]
Нужно смотреть на момент когда возникает ошибка или зависание
/var/log/kern.log.
On 04.08.2015 22:15, Илья wrote:
Я смог вызвать эту ошибку двумя способами (выдает именно это сообщение sh:
echo: I/O error):
1) swapoff -a
но тут понятно - система даже ругается.
Интересно - почему? Откуда I/O error?
Мне не понятно.
Почему не понятно? Устройство отключено, а в него
On 2015-08-03 07:12, Илья wrote:
Я считаю, что на больших объемах ОЗУ можно вообще отказаться от свопа ,
а для hibernate использовать либо свой pm hook (swapon,swapoff), либо
какой то
специфический параметр виртуальной памяти, что то типа overcommit_ratio.
В конкретно этой ситуации можно
Случайно выяснилось (при освобождении памяти), что такая ошибка возникает в 3 случае.pm-suspend.log:Initial commandline parameters: Пн. авг. 3 00:17:36 MSK 2015: Running hooks for hibernate.Running hook /usr/lib/pm-utils/sleep.d/000kernel-change hibernate hibernate:... total
2015-08-03 9:24 GMT+03:00 Илья mir...@yandex.ru:
total used free sharedbuffers cached
Память:2063884 8268921236992 1064 17720 85756
-/+ буферы/кэш: 7234161340468
Подкачка:22425562240568 1988
...
а не
Я делал синтетические тесты - в реальности у меня таких проблем не возникает.Будет свободное время попробую, но... Как я понял этот параметр действует по направлению ram - swap, а не обратно.Я считаю, что на больших объемах ОЗУ можно вообще отказаться от свопа ,а для hibernate использовать либо
On 03.08.2015 14:12, Илья wrote:
Я делал синтетические тесты - в реальности у меня таких проблем не возникает.
Будет свободное время попробую, но...
Как я понял этот параметр действует по направлению ram - swap, а не обратно.
Да.
Я считаю, что на больших объемах ОЗУ можно вообще отказаться от
On 08/03/15 22:36, Артём Н. wrote:
а не пробовали vm.swappiness (sysctl) менять? по умолчанию вроде 60 ,
поставьте в диапазоне 1-5
Я пробовал.
# sysctl vm.swappiness
vm.swappiness = 2
Естественно, что при 20 Гб RAM, 60% - это слишком.
Я не помню точную семантику этого числа, но это
On 03.08.2015 17:43, Tim Sattarov wrote:
On 2015-08-03 07:12, Илья wrote:
Я считаю, что на больших объемах ОЗУ можно вообще отказаться от свопа ,
а для hibernate использовать либо свой pm hook (swapon,swapoff), либо
какой то
специфический параметр виртуальной памяти, что то типа
On 03.08.2015 22:50, Vasiliy P. Melnik wrote:
Указывать системе, какой своп юзать (помню, была в fstab опция,
позволяющая распределить нагрузку), а hibernate указать UID
раздела?
Всё же не совсем приятно, что своп будет в файле: там получится три уровня
под ним
вы
On 02.08.2015 20:12, Aleksandr Sytar wrote:
Если ядро собрано с поддержкой slab/slub - то кто конкретно держит память
можно посмотреть через cat /proc/slabinfo Теоретически
там не должно быть записей относительно процессов которые уже выгружены.
Собрано с поддержкой, только вот как их этого
On 03.08.2015 22:44, Alex Kicelew wrote:
On 08/03/15 22:36, Артём Н. wrote:
а не пробовали vm.swappiness (sysctl) менять? по умолчанию вроде 60 ,
поставьте в диапазоне 1-5
Я пробовал.
# sysctl vm.swappiness
vm.swappiness = 2
Естественно, что при 20 Гб RAM, 60% - это слишком.
Я не помню
On 03.08.2015 11:45, Anatoly Pugachev wrote:
2015-08-03 9:24 GMT+03:00 Илья mir...@yandex.ru mailto:mir...@yandex.ru:
total used free sharedbuffers cached
Память:2063884 8268921236992 1064 17720 85756
-/+ буферы/кэш:
Указывать системе, какой своп юзать (помню, была в fstab опция,
позволяющая распределить нагрузку), а hibernate указать UID раздела?
Всё же не совсем приятно, что своп будет в файле: там получится три уровня
под ним
вы столько это обговариваете, что уже можно было пойти купить 16 гигов
On 03.08.2015 00:08, Илья wrote:
я думаю это ругается /usr/lib/pm-utils/pm-functions:
При выборе режима сна? С чего бы?
К долгому сохранению (кстати, сколько по времени не могли дождаться и прерывали?) это
возможно не относится, эта ошибка о том, что не смог уснуть .
В районе 5-10 минут.
Я не помню точную семантику этого числа, но это однозначно не проценты.
В отличие от процентов, которых не может быть больше 100, это число не
ограничено сверху (точнее, ограничено размерностью инта).
Хотя... В страницах?
amount of free and file-backed pages is less
than the high water mark in a
On 01.08.2015 06:16, ivan demakov wrote:
On Wednesday, July 29, 2015 20:11:19 Артём Н. wrote:
Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
чего он умирает.
dmesg ничего не даёт (плюс ещё, он загажен криво настроенным AppArmor).
И он не то, чтобы умирает: очень
On 31.07.2015 12:16, Илья wrote:
Три ошибки:
1) sync не вызывает sh: и echo: ...
Согласен, не прав, я думаю это ругается /usr/lib/pm-utils/pm-functions:
if [ -z $HIBERNATE_MODULE ] \
[ -f /sys/power/disk ] \
grep -q disk /sys/power/state; then
2 августа 2015 г., 17:45 пользователь Артём Н. artio...@yandex.ru
написал:
Смешно. Для того, чтобы узнать под какие буфера распределяется память, не
обязательно обращаться к исходникам.
На это есть документация (весь вопрос в том, что читать).
Впрочем, не будем разводить флейм. Этот ответ ещё
On Wednesday, July 29, 2015 20:11:19 Артём Н. wrote:
Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
чего он умирает.
dmesg ничего не даёт (плюс ещё, он загажен криво настроенным AppArmor).
И он не то, чтобы умирает: очень долго пытается уснуть, постоянно
2015-07-29 20:18 GMT+03:00 Артём Н. artio...@yandex.ru:
29.07.2015 08:24, Артём Н. пишет:
Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и
всё
ok?
В любом случае, запись 10 Гб (да, проблемы с hibernate начинаются
после долгой работы),
не
В Wed, 29 Jul 2015 08:44:43 +0300 Артём писал:
Последнее время я использую не pm-hibernate, а пункт меню Спящий
режим в KDE.
Попробуйте из консоли/окна терминала дать команду -- чисто для
сравнения: и по скорости работы и по записям в журналах.
Всего доброго, Ста.
Справка к моим
Здравствуйте, Артём.
В Wed, 29 Jul 2015 08:24:35 +0300 вы писали:
Да, пусть не утекает, а используется про запас.
Так работает ОС. Конечно, вы можете сие изменить, поиграв параметрами
процессов сброса запасу «pdflush»: /proc/sys/vm/dirty_* .
А проблемы со «спячкой» -- вероятно, лежат в
В Wed, 29 Jul 2015 20:11:19 +0300 Артём писал:
dmesg ничего не даёт (плюс ещё, он загажен криво настроенным
AppArmor). И он не то, чтобы умирает: очень долго пытается уснуть,
постоянно обращается к диску. В итоге, я не жду, и выключаю: потом
fsck показывает, что ФС немного порушена.
Это
On 30.07.2015 17:36, Andrey Melnikoff wrote:
Артём Н. artio...@yandex.ru wrote:
Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
чего он умирает.
dmesg ничего не даёт (плюс ещё, он загажен криво настроенным AppArmor).
И он не то, чтобы умирает: очень долго пытается
On 2015-07-30 13:26, Артём Н. wrote:
Так, наверное проблема проявляется при начале записи?
Это из твоих логов hibernate
Ср июн 24 20:09:45 MSK 2015: performing hibernate
sh: echo: I/O error
Ср июн 24 20:10:08 MSK 2015: Awake.
проверь лог сразу после проблемы, чтобы захватить события которые
Кол-во процессов (чем больше -- значит: больше ожидается на
запись), м/о посмотреть так:
/bin/cat /proc/sys/vm/nr_pdflush_threads
Если ноль -- значит, «В Багдаде всё спокойно.» /«КарМэн»/ :о) -- Т.е.
нет проблем с записью на диск.
Сейчас 0. Спасибо за наводку. Посмотрю перед следующей спячкой.
On 30.07.2015 16:38, Ста Деюс wrote:
В Wed, 29 Jul 2015 20:11:19 +0300 Артём писал:
dmesg ничего не даёт (плюс ещё, он загажен криво настроенным
AppArmor). И он не то, чтобы умирает: очень долго пытается уснуть,
постоянно обращается к диску. В итоге, я не жду, и выключаю: потом
fsck
вместо echo 1 , echo 3 пробовали?
Ну да, там по какой-то из ссылок было же. Я от 4-х до 0 попробовал. 3-1 прокатили, но сильного сброса я не заметил (может плохо
смотрел).
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On 30.07.2015 16:27, Ста Деюс wrote:
В Wed, 29 Jul 2015 08:44:43 +0300 Артём писал:
Последнее время я использую не pm-hibernate, а пункт меню Спящий
режим в KDE.
Попробуйте из консоли/окна терминала дать команду -- чисто для
сравнения: и по скорости работы и по записям в журналах.
Раньше
On 30.07.2015 18:23, Илья wrote:
Хотелось бы узнать у знатоков : если предположим, swap практически весь
забит, то при входе в ждущий режим, что с ним происходит?
Вот, и мне хотелось бы узнать.
Вопросы автору топика:
1 Почему вы решили, что проблема связана памятью, какие критерии ?
Ну,
On 30.07.2015 20:31, Tim Sattarov wrote:
On 2015-07-30 13:26, Артём Н. wrote:
Так, наверное проблема проявляется при начале записи?
Это из твоих логов hibernate
Ср июн 24 20:09:45 MSK 2015: performing hibernate
sh: echo: I/O error
Ср июн 24 20:10:08 MSK 2015: Awake.
Thanx, я сразу не
On 2015-07-30 14:12, Илья wrote:
Это sync ругается в /usr/sbin/pm-hibernate:
# run the sleep hooks
log $(date): Running hooks for $ACTION.
if run_hooks sleep $ACTION $METHOD; then
# Sleep only if we know how and if a hook did not inhibit us.
log $(date): performing $METHOD
On 2015-07-29 13:16, Артём Н. wrote:
Да, сбрасывает.
Долго пишет.
Получается, что те 6.2 гига которые остаются неизменными и есть реально
занятая память.
надо смотреть кто их занимает.
У тебя случайно не настроены хитрые приблуды. которые скрывают процессы
или как то разделяют права доступа к
29.07.2015 08:24, Артём Н. пишет:
Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и всё
ok?
В любом случае, запись 10 Гб (да, проблемы с hibernate начинаются
после долгой работы),
не быстрая процедура. Собственно, мне такого не надо.
Система периодически сбрасывает
29 июля 2015 г., 18:15 пользователь aleksey li...@mail.ru написал:
29.07.2015 08:24, Артём Н. пишет:
Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и всё
ok?
В любом случае, запись 10 Гб (да, проблемы с hibernate начинаются
после долгой работы),
не быстрая процедура.
Если у тебя умирает гибернейт - то надо смотреть хотя-бы в вывод dmesg, от
чего он умирает.
dmesg ничего не даёт (плюс ещё, он загажен криво настроенным AppArmor).
И он не то, чтобы умирает: очень долго пытается уснуть, постоянно обращается
к диску.
В итоге, я не жду, и выключаю: потом fsck
29.07.2015 08:24, Артём Н. пишет:
Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и всё
ok?
В любом случае, запись 10 Гб (да, проблемы с hibernate начинаются
после долгой работы),
не быстрая процедура. Собственно, мне такого не надо.
Система
Да, сбрасывает.
Долго пишет.
root@danroot@dana:/home# free ; dd if=/dev/zero of=test.dump bs=1024
count=16353480 ; rm -f test.dump
total used free sharedbuffers cached
Mem: 19G 7,7G11G 335M 666M 1,3G
-/+
On 29.07.2015 22:19, Mikhail A Antonov wrote:
29.07.2015 08:15, Артём Н. пишет:
Ну, так подо что cached?
Дисковый кеш, библиотеки, сетевые буферы и прочее.
Если коротко - не мешай системе работать. Как только эта память потребуется для
реального приложения - она будет доступна.
Да, я увидел
Самое главное - сумма занятой памяти совпадает ? :)
Сложно сказать: много процессов.
Я бы задумался если нет, попробовал бы проапгрейдить систему ... те же
util-linux.
проверить debsums и прочее.
Подобные данные ввели бы меня в параноидальное состояние и полную
проверку системы, пока не найду
29.07.2015 08:15, Артём Н. пишет:
Ну, так подо что cached?
Дисковый кеш, библиотеки, сетевые буферы и прочее.
Если коротко - не мешай системе работать. Как только эта память потребуется
для
реального приложения - она будет доступна.
Да, я увидел это по ссылке. Но don't worry не получается.
Получается, что те 6.2 гига которые остаются неизменными и есть реально
занятая память.
надо смотреть кто их занимает.
1. XUL паршивый - это то, что жрёт память в огромных масштабах на всех
платформах.
Firefox+icedove.
2. Chromium.
3. Okular.
4. Java.
5. Mysqld.
6. Amarok.
7. Прочее.
У
On 2015-07-29 13:34, Артём Н. wrote:
Получается, что те 6.2 гига которые остаются неизменными и есть реально
занятая память.
надо смотреть кто их занимает.
1. XUL паршивый - это то, что жрёт память в огромных масштабах на всех
платформах.
Firefox+icedove.
2. Chromium.
3. Okular.
4.
Артём Н. artio...@yandex.ru wrote:
Ну, так подо что cached?
Дисковый кеш, библиотеки, сетевые буферы и прочее.
Если коротко - не мешай системе работать. Как только эта память потребуется
для
реального приложения - она будет доступна.
Да, я увидел это по ссылке. Но don't worry не
On 2015-07-27 15:41, Артём Н. wrote:
On 27.07.2015 21:38, Max Dmitrichenko wrote:
в последней колонке cached 8,8G
Ну, так подо что cached?
Попробуй вот так:
free ; dd if=/dev/zero of=test.dump bs=1024 count=16353480 ; rm -f
test.dump; free
вот что выдает у меня (я немного
Да, забыл сказать.
Последнее время я использую не pm-hibernate, а пункт меню Спящий режим в KDE.
В логи, вероятно, при этом ничего не пишется (но проблема уже давно):
-rw-r--r-- 1 root root0 июн 25 22:44 /var/log/pm-powersave.log
-rw-r--r-- 1 root root 33K июн 24 21:40
Ну, так подо что cached?
Дисковый кеш, библиотеки, сетевые буферы и прочее.
Если коротко - не мешай системе работать. Как только эта память потребуется для
реального приложения - она будет доступна.
Да, я увидел это по ссылке. Но don't worry не получается.
Проблема не в выводе free, а в том,
Из того, что вы привели, не видно, чтобы ОЗУ куда-то «утекало». ОС
использует ОЗУ про запас -- что нормально.
Да, пусть не утекает, а используется про запас.
А проблемы со «спячкой» -- вероятно, лежат в ином.
Т.е., вы хотите сказать, что перед этим кэш сбрасывается на диск и всё ok?
В любом
http://www.linuxatemyram.com/
You can't disable disk caching. The only reason anyone ever wants to disable disk caching is because they think it takes memory
away from their applications, which it doesn't! You can't disable disk caching. The only reason anyone ever wants to disable disk
caching
Здравствуйте, Артём.
В Mon, 27 Jul 2015 21:14:39 +0300 вы писали:
После убийства процессов, требовательных к памяти (firefox, chromium,
icedove), остаются использованными 14-10 Гб. Куда она утекает? Под
какой-нибудь кэш? Как это понять?
Проблема в том, что hibernate, при таком использовании
Почему-то система использует 15 Гб памяти.
root@dana:~# free
total used free sharedbuffers cached
Mem: 19G15G 4,5G 328M 931M 8,8G
-/+ buffers/cache: 5,4G14G
Swap: 29G 0B29G
On 2015-07-27 14:14, Артём Н. wrote:
Почему-то система использует 15 Гб памяти.
root@dana:~# free
total used free sharedbuffers cached
Mem: 19G15G 4,5G 328M 931M 8,8G
-/+ buffers/cache: 5,4G14G
навскидку - что за куча okular'ов? сколько их там еще?
2015-208 21:14 Артём Н. artio...@yandex.ru wrote:
Почему-то система использует 15 Гб памяти.
root@dana:~# free
total used free sharedbuffers cached
Mem: 19G15G 4,5G
в последней колонке cached 8,8G
2015-07-27 21:14 GMT+03:00 Артём Н. artio...@yandex.ru:
Почему-то система использует 15 Гб памяти.
root@dana:~# free
total used free sharedbuffers cached
Mem: 19G15G 4,5G 328M 931M
On 2015-07-27 14:38, Max Dmitrichenko wrote:
в последней колонке cached 8,8G
Это был мой первый ответ.
но потом я посмотрел на вывод своего free:
# free -h
totalusedfree shared buff/cache
available
Mem:15G899M2.7G 24M
On 27.07.2015 21:44, Tim Sattarov wrote:
ps axo %mem,cmd k -%mem | grep -v 0.0
Ничего криминального. От силы 15% наберётся, а это около 3 Гб. Собственно, прибив всё столько же (ну чуть больше/меньше) и
освобождается, а 10 Гб остаются заняты.
%MEM CMD=
2.6 /usr/lib/firefox/firefox
1.8
On 27.07.2015 21:51, Tim Sattarov wrote:
On 2015-07-27 14:38, Max Dmitrichenko wrote:
в последней колонке cached 8,8G
Это был мой первый ответ.
но потом я посмотрел на вывод своего free:
И..?
# free -h
totalusedfree shared buff/cache
available
Mem:
навскидку - что за куча okular'ов? сколько их там еще?
Книжки недочитанные. Около 15. После убийства освобождается 1.5-2 Гб, которые я
посчитал.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 27.07.2015 21:38, Max Dmitrichenko wrote:
в последней колонке cached 8,8G
Ну, так подо что cached?
2015-07-27 21:14 GMT+03:00 Артём Н. artio...@yandex.ru
mailto:artio...@yandex.ru:
Почему-то система использует 15 Гб памяти.
root@dana:~# free
total used
On 2015-07-27 15:41, Артём Н. wrote:
On 27.07.2015 21:38, Max Dmitrichenko wrote:
в последней колонке cached 8,8G
Ну, так подо что cached?
http://www.linuxatemyram.com/
2015-07-27 21:14 GMT+03:00 Артём Н. artio...@yandex.ru
mailto:artio...@yandex.ru:
Почему-то система использует 15
27.07.2015 22:41, Артём Н. пишет:
On 27.07.2015 21:38, Max Dmitrichenko wrote:
в последней колонке cached 8,8G
Ну, так подо что cached?
Дисковый кеш, библиотеки, сетевые буферы и прочее.
Если коротко - не мешай системе работать. Как только эта память потребуется для
реального приложения - она
69 matches
Mail list logo