Ответ Yuugian является определенно безопасным и надлежащим способом пойти. Но для некоторых людей, могло бы быть хорошо знать, что можно на самом деле сделать это, даже не закрывая рабочую систему. Можно рассматривать этот ответ как учебное или последнее средство в ситуациях, где начальная загрузка от liveCD не является опцией.
Отказ от ответственности: Эта процедура не рекомендуется для пользователей новичка. Если Вы не помещаете достаточно внимания к шагу 1, Ваша система могла бы отказать, в то время как Вы выполняете следующие шаги, и можно испытать неожиданное поведение различных приложений после перезагрузки. Перед попыткой этого необходимо проверить, что Вы знакомы с /var
описание на tldp и Ваших определенных для распределения отклонениях от этого.
Близкие программы, которые имеют открытые файлы под /var
. Запустите путем переключения на консоль (один из "реальных" ttys) и закрытия X-сервера, а также среды рабочего стола (kdm/gdm/lightdm/...) при использовании того. Если Вы не знаете, как сделать это или что это означает, НЕ продолжайте - возможности, что Вы могли бы повредить Вас, система слишком высока, и существует только слишком много возможностей покрыть в пошаговой процедуре здесь - извините!
Использовать lsof
или fuser
найти остающиеся программы, которые имеют файлы, открытые под /var
. Заметьте, что, если программа была запущена как системная служба, всегда лучше остановить сервис, вместо того, чтобы уничтожить задачу. Если существуют некоторые программы/сервисы, слишком упрямые для контакта с этим путем, Вы могли бы также попытаться переключиться на однопользовательский режим (init уровень 1) - если это приемлемо для Вас. В большинстве случаев было бы нормально иметь несколько (!) файлов, все еще открываются под /var
- например, изодромные с предварением файлы под /var/run
, в случае, если Ваша система использует то местоположение.
Смонтируйте свой корневой раздел (во второй раз). Просто выберите любой пустой каталог в качестве временной точки монтирования для того - я буду использовать /mnt/tmp
как пример. Обычно mount
команда (без параметров) не отобразит название физического устройства позади Вашего корневого раздела, необходимо будет проверить, какой - это (если Вы не знаете наверняка). Можно обычно получать информацию любой от lsblk
(если у Вас есть он в Вашей системе), или конфигурация загрузчика, или cat /proc/cmdline
, или путем идентификации раздела размером, о котором сообщают fdisk
.
Копия /var
содержание. После того как Вы нашли раздел и смонтировали его, скопируйте содержание /var
к Вашему rootfs (смонтированный в новом месте), с помощью cp -ad
, такой как: cp -ad /var /mnt/tmp/
.Примечание: если Ваш дистрибутив все еще справляется /var/run
и /var/lock
каталоги вместо недавно представленного /run/
, необходимо пропустить содержание этих двух каталогов. Если extglob включен в Вашей оболочке, можно сделать то использование cp -ad /var/!(run|lock) /mnt/tmp/var/
- или используйте cpio
вместо этого. Только создать эти два каталога под /mnt/tmp/var/
и набор их полномочия правильно после копирования.
Удалите старый /var
запись в fstab
. Безопасный путь состоит в том, чтобы прокомментировать его, конечно.
Перезагрузка
Я не уверен, которые регистрируются, Вы на самом деле обращаетесь к, но существует система регистрации, это часто включается с большинством названных дистрибутивов sar
, это обычно находится в названном пакете sysstat
.
Также я описал это Вопросы и ответы U&L, который покрывает множество методов для входа информации о производительности, названной: "Команды для определения уровня использования сервера"
В вашем случае у вас 512 RAM + 1GB Swap памяти. Таким образом, теоретически, ваш процессор имеет доступ к 1,5 ГБ виртуальной памяти.
Итак, некоторое время все работает нормально в пределах 1,5 ГБ общей памяти. Но внезапно (или постепенно) ваша система начала потреблять все больше и больше памяти и достигла точки около 95% от общего объема используемой памяти.
Теперь предположим, что какой-либо процесс (в вашем случае python) запросил у ядра большой кусок памяти. Ядро проверяет доступную память и обнаруживает, что оно никак не может выделить процессу больше памяти. Поэтому оно попытается освободить часть памяти, вызвав OOMKiller (http://linux-mm.org/OOM).
OOMKiller имеет свой собственный алгоритм для оценки ранга для каждого процесса. Обычно тот процесс, который использует больше памяти, становится жертвой (python в вашем первом наборе логов; и smbd в более позднем разделе логов).
Обычно в каталоге /var/log. Либо /var/log/kern.log или /var/log/dmesg