Вопросы Теги

Почему мой сервер зависает каждый день в одно и то же время?

Вы можете использовать следующую команду для добавления отпечатка пальца для сервера к вашим известным_hosts 

ssh-keyscan -H <ip-address> >> ~/.ssh/known_hosts
ssh-keyscan -H <hostname> >> ~/.ssh/known_hosts

ПРИМЕЧАНИЕ. Замените & lt; ip-address> и & lt; hostname> с именем IP и dns сервера, который вы хотите добавить.

Единственная проблема заключается в том, что в конечном итоге у вас будет несколько серверов в ваших known_hosts. Это не очень много, просто упомянуть. Чтобы убедиться, что дубликатов нет, вы можете сначала удалить все серверы, выполнив следующее: 

ssh-keygen -R <ip-address>
ssh-keygen -R <hostname>

. Таким образом, вы можете запустить: 

for h in $SERVER_LIST; do
    ip=$(dig +search +short $h)
    ssh-keygen -R $h
    ssh-keygen -R $ip
    ssh-keyscan -H $ip >> ~/.ssh/known_hosts
    ssh-keyscan -H $h >> ~/.ssh/known_hosts
done

ум при удалении только для повторного добавления, вы по существу устраняете безопасность проверки отпечатка пальца. Таким образом, вы не захотите запускать этот скрипт перед каждым исполнением вашего скрипта утилиты.

4
задан 9 July 2012 в 17:10

17 ответов

Решение было сообщено здесь: http://www.hskupin.info/2010/06/17/how-to-fix-the-oom-killer-crashe-under-linux/

Так, что случилось? Причина может быть объяснена вкратце: ядро ​​Linux любит всегда выделять память, если приложения запрашивают ее. По умолчанию он не проверяет, достаточно ли памяти. Учитывая такое поведение, приложения могут выделять больше памяти, насколько это реально доступно. В какой-то момент это может определенно вызвать нехватку памяти. В результате будет вызван OOM killer, который убьет этот процесс: 

Jun 11 11:35:21 vsrv03 kernel: [378878.356858] php-cgi invoked oom-killer: gfp_mask=0x1280d2, order=0, oomkilladj=0
Jun 11 11:36:11 vsrv03 kernel: [378878.356880] Pid: 8490, comm: php-cgi Not tainted 2.6.26-2-xen-amd64 #1

Недостатком этого действия является то, что все остальные запущенные процессы также будут затронуты. В результате вся виртуальная машина не работала и нуждалась в перезапуске.

Чтобы исправить эту проблему, необходимо изменить поведение ядра, чтобы оно больше не перезапускало память для запросов приложений. Наконец, я включил эти упомянутые значения в файл /etc/sysctl.conf, чтобы они автоматически применялись при запуске: 

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

(перезагрузите, чтобы применить изменения.)

Подробнее о сверхкоммитах: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6

4
ответ дан 25 July 2018 в 18:09

Решение было сообщено здесь: http://www.hskupin.info/2010/06/17/how-to-fix-the-oom-killer-crashe-under-linux/

Так, что случилось? Причина может быть объяснена вкратце: ядро ​​Linux любит всегда выделять память, если приложения запрашивают ее. По умолчанию он не проверяет, достаточно ли памяти. Учитывая такое поведение, приложения могут выделять больше памяти, насколько это реально доступно. В какой-то момент это может определенно вызвать нехватку памяти. В результате будет вызван OOM killer, который убьет этот процесс: 

Jun 11 11:35:21 vsrv03 kernel: [378878.356858] php-cgi invoked oom-killer: gfp_mask=0x1280d2, order=0, oomkilladj=0
Jun 11 11:36:11 vsrv03 kernel: [378878.356880] Pid: 8490, comm: php-cgi Not tainted 2.6.26-2-xen-amd64 #1

Недостатком этого действия является то, что все остальные запущенные процессы также будут затронуты. В результате вся виртуальная машина не работала и нуждалась в перезапуске.

Чтобы исправить эту проблему, необходимо изменить поведение ядра, чтобы оно больше не перезапускало память для запросов приложений. Наконец, я включил эти упомянутые значения в файл /etc/sysctl.conf, чтобы они автоматически применялись при запуске: 

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

(перезагрузите, чтобы применить изменения.)

Подробнее о сверхкоммитах: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6

4
ответ дан 31 July 2018 в 12:48

Решение было сообщено здесь: http://www.hskupin.info/2010/06/17/how-to-fix-the-oom-killer-crashe-under-linux/

Так, что случилось? Причина может быть объяснена вкратце: ядро ​​Linux любит всегда выделять память, если приложения запрашивают ее. По умолчанию он не проверяет, достаточно ли памяти. Учитывая такое поведение, приложения могут выделять больше памяти, насколько это реально доступно. В какой-то момент это может определенно вызвать нехватку памяти. В результате будет вызван OOM killer, который убьет этот процесс: 

Jun 11 11:35:21 vsrv03 kernel: [378878.356858] php-cgi invoked oom-killer: gfp_mask=0x1280d2, order=0, oomkilladj=0
Jun 11 11:36:11 vsrv03 kernel: [378878.356880] Pid: 8490, comm: php-cgi Not tainted 2.6.26-2-xen-amd64 #1

Недостатком этого действия является то, что все остальные запущенные процессы также будут затронуты. В результате вся виртуальная машина не работала и нуждалась в перезапуске.

Чтобы исправить эту проблему, необходимо изменить поведение ядра, чтобы оно больше не перезапускало память для запросов приложений. Наконец, я включил эти упомянутые значения в файл /etc/sysctl.conf, чтобы они автоматически применялись при запуске: 

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

(перезагрузите, чтобы применить изменения.)

Подробнее о сверхкоммитах: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6

4
ответ дан 2 August 2018 в 00:23

Решение было сообщено здесь: http://www.hskupin.info/2010/06/17/how-to-fix-the-oom-killer-crashe-under-linux/

Так, что случилось? Причина может быть объяснена вкратце: ядро ​​Linux любит всегда выделять память, если приложения запрашивают ее. По умолчанию он не проверяет, достаточно ли памяти. Учитывая такое поведение, приложения могут выделять больше памяти, насколько это реально доступно. В какой-то момент это может определенно вызвать нехватку памяти. В результате будет вызван OOM killer, который убьет этот процесс: 

Jun 11 11:35:21 vsrv03 kernel: [378878.356858] php-cgi invoked oom-killer: gfp_mask=0x1280d2, order=0, oomkilladj=0
Jun 11 11:36:11 vsrv03 kernel: [378878.356880] Pid: 8490, comm: php-cgi Not tainted 2.6.26-2-xen-amd64 #1

Недостатком этого действия является то, что все остальные запущенные процессы также будут затронуты. В результате вся виртуальная машина не работала и нуждалась в перезапуске.

Чтобы исправить эту проблему, необходимо изменить поведение ядра, чтобы оно больше не перезапускало память для запросов приложений. Наконец, я включил эти упомянутые значения в файл /etc/sysctl.conf, чтобы они автоматически применялись при запуске: 

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

(перезагрузите, чтобы применить изменения.)

Подробнее о сверхкоммитах: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6

4
ответ дан 4 August 2018 в 15:52

Решение было сообщено здесь: http://www.hskupin.info/2010/06/17/how-to-fix-the-oom-killer-crashe-under-linux/

Так, что случилось? Причина может быть объяснена вкратце: ядро ​​Linux любит всегда выделять память, если приложения запрашивают ее. По умолчанию он не проверяет, достаточно ли памяти. Учитывая такое поведение, приложения могут выделять больше памяти, насколько это реально доступно. В какой-то момент это может определенно вызвать нехватку памяти. В результате будет вызван OOM killer, который убьет этот процесс: 

Jun 11 11:35:21 vsrv03 kernel: [378878.356858] php-cgi invoked oom-killer: gfp_mask=0x1280d2, order=0, oomkilladj=0
Jun 11 11:36:11 vsrv03 kernel: [378878.356880] Pid: 8490, comm: php-cgi Not tainted 2.6.26-2-xen-amd64 #1

Недостатком этого действия является то, что все остальные запущенные процессы также будут затронуты. В результате вся виртуальная машина не работала и нуждалась в перезапуске.

Чтобы исправить эту проблему, необходимо изменить поведение ядра, чтобы оно больше не перезапускало память для запросов приложений. Наконец, я включил эти упомянутые значения в файл /etc/sysctl.conf, чтобы они автоматически применялись при запуске: 

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

(перезагрузите, чтобы применить изменения.)

Подробнее о сверхкоммитах: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6

4
ответ дан 6 August 2018 в 00:30

Решение было сообщено здесь: http://www.hskupin.info/2010/06/17/how-to-fix-the-oom-killer-crashe-under-linux/

Так, что случилось? Причина может быть объяснена вкратце: ядро ​​Linux любит всегда выделять память, если приложения запрашивают ее. По умолчанию он не проверяет, достаточно ли памяти. Учитывая такое поведение, приложения могут выделять больше памяти, насколько это реально доступно. В какой-то момент это может определенно вызвать нехватку памяти. В результате будет вызван OOM killer, который убьет этот процесс: 

Jun 11 11:35:21 vsrv03 kernel: [378878.356858] php-cgi invoked oom-killer: gfp_mask=0x1280d2, order=0, oomkilladj=0
Jun 11 11:36:11 vsrv03 kernel: [378878.356880] Pid: 8490, comm: php-cgi Not tainted 2.6.26-2-xen-amd64 #1

Недостатком этого действия является то, что все остальные запущенные процессы также будут затронуты. В результате вся виртуальная машина не работала и нуждалась в перезапуске.

Чтобы исправить эту проблему, необходимо изменить поведение ядра, чтобы оно больше не перезапускало память для запросов приложений. Наконец, я включил эти упомянутые значения в файл /etc/sysctl.conf, чтобы они автоматически применялись при запуске: 

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

(перезагрузите, чтобы применить изменения.)

Подробнее о сверхкоммитах: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6

4
ответ дан 7 August 2018 в 17:54

Решение было сообщено здесь: http://www.hskupin.info/2010/06/17/how-to-fix-the-oom-killer-crashe-under-linux/

Так, что случилось? Причина может быть объяснена вкратце: ядро ​​Linux любит всегда выделять память, если приложения запрашивают ее. По умолчанию он не проверяет, достаточно ли памяти. Учитывая такое поведение, приложения могут выделять больше памяти, насколько это реально доступно. В какой-то момент это может определенно вызвать нехватку памяти. В результате будет вызван OOM killer, который убьет этот процесс: 

Jun 11 11:35:21 vsrv03 kernel: [378878.356858] php-cgi invoked oom-killer: gfp_mask=0x1280d2, order=0, oomkilladj=0
Jun 11 11:36:11 vsrv03 kernel: [378878.356880] Pid: 8490, comm: php-cgi Not tainted 2.6.26-2-xen-amd64 #1

Недостатком этого действия является то, что все остальные запущенные процессы также будут затронуты. В результате вся виртуальная машина не работала и нуждалась в перезапуске.

Чтобы исправить эту проблему, необходимо изменить поведение ядра, чтобы оно больше не перезапускало память для запросов приложений. Наконец, я включил эти упомянутые значения в файл /etc/sysctl.conf, чтобы они автоматически применялись при запуске: 

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

(перезагрузите, чтобы применить изменения.)

Подробнее о сверхкоммитах: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6

4
ответ дан 10 August 2018 в 06:45

Решение было сообщено здесь: http://www.hskupin.info/2010/06/17/how-to-fix-the-oom-killer-crashe-under-linux/

Так, что случилось? Причина может быть объяснена вкратце: ядро ​​Linux любит всегда выделять память, если приложения запрашивают ее. По умолчанию он не проверяет, достаточно ли памяти. Учитывая такое поведение, приложения могут выделять больше памяти, насколько это реально доступно. В какой-то момент это может определенно вызвать нехватку памяти. В результате будет вызван OOM killer, который убьет этот процесс: 

Jun 11 11:35:21 vsrv03 kernel: [378878.356858] php-cgi invoked oom-killer: gfp_mask=0x1280d2, order=0, oomkilladj=0
Jun 11 11:36:11 vsrv03 kernel: [378878.356880] Pid: 8490, comm: php-cgi Not tainted 2.6.26-2-xen-amd64 #1

Недостатком этого действия является то, что все остальные запущенные процессы также будут затронуты. В результате вся виртуальная машина не работала и нуждалась в перезапуске.

Чтобы исправить эту проблему, необходимо изменить поведение ядра, чтобы оно больше не перезапускало память для запросов приложений. Наконец, я включил эти упомянутые значения в файл /etc/sysctl.conf, чтобы они автоматически применялись при запуске: 

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

(перезагрузите, чтобы применить изменения.)

Подробнее о сверхкоммитах: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6

4
ответ дан 15 August 2018 в 18:38
  • 1
    Так что эти две строчки решат проблему ?? – Zbyněk Nedoma 9 July 2012 в 18:05
  • 2
    Я не проверял это, я надеялся, что вы и дайте нам знать. :) – Savvas Radevic 9 July 2012 в 21:56
  • 3
    Я пробовал и пока сервер не падая. Спасибо – Zbyněk Nedoma 11 July 2012 в 16:30

Что происходит, просто, почему нет (нужна дополнительная информация).

php5-cgi начинает использовать в то время много памяти (может быть утечка памяти или побочный эффект), настолько, что у системы закончится память. Таким образом, ядро ​​убивает его (oom-killer - это убийца без памяти ядра) для поддержания стабильности системы.

Это похоже на VPS - не так ли? Какие? Ошибки OOM обычно встречаются редко на физических машинах с достаточной (1 ГБ +) оперативной памятью и местом подкачки (по крайней мере, по крайней мере 2 RAM).

3
ответ дан 25 May 2018 в 08:51
  • 1
    Он выделяет сервер Kimsufi 2G: kimsufi.co.uk . ОЗУ составляет 2 ГБ, а процессор - Intel Atom 1,20+ ГГц. – Zbyněk Nedoma 9 July 2012 в 17:19
  • 2
    @ ZbyněkNedoma: Благодарю вас, я посмотрю ваш журнал в течение нескольких часов и попытаюсь выяснить больше. Что делает php5-cgi в или непосредственно перед 00:50? Что-то вызывает его ... – ish 9 July 2012 в 17:21
  • 3
    В syslog я нашел это: drwebd.real: Loading /var/drweb/bases/drwnasty.vdb - Ok, virus records: 28348 drwebd.real: Total virus records: 3473166 drwebd.real: Key file: /opt/drweb/drweb32.key - Key file was not found! (No such file or directory) drwebd.real: A path to a valid license key file was not specified. drwebd.real: Daemon is enabled for protecting 0 e-mails: drwebd.real: Daemon is installed, active interfaces: /var/drweb/run/.daemon 127.0.0.1:3000 CRON[20081]: (root) CMD (/usr/local/rtm/bin/rtm 8 > /dev/null 2> /dev/null) ..... Repeat this about 20 times – Zbyněk Nedoma 9 July 2012 в 18:01

То, что происходит, просто, а почему нет (нужно больше информации).

php5-cgi начинает использовать много памяти в это время (это может быть утечка памяти или побочный эффект), настолько, что системе не хватит памяти. Таким образом, ядро ​​убивает его (oom-killer - убийца нехватки памяти ядра) для поддержания стабильности системы.

Это похоже на VPS - так? Какие? Ошибки OOM, как правило, встречаются редко на физических машинах с достаточным (1 ГБ +) ОЗУ и местом подкачки (не менее 2 ОЗУ).

3
ответ дан 25 July 2018 в 18:09

То, что происходит, просто, а почему нет (нужно больше информации).

php5-cgi начинает использовать много памяти в это время (это может быть утечка памяти или побочный эффект), настолько, что системе не хватит памяти. Таким образом, ядро ​​убивает его (oom-killer - убийца нехватки памяти ядра) для поддержания стабильности системы.

Это похоже на VPS - так? Какие? Ошибки OOM, как правило, встречаются редко на физических машинах с достаточным (1 ГБ +) ОЗУ и местом подкачки (не менее 2 ОЗУ).

3
ответ дан 31 July 2018 в 12:48

То, что происходит, просто, а почему нет (нужно больше информации).

php5-cgi начинает использовать много памяти в это время (это может быть утечка памяти или побочный эффект), настолько, что системе не хватит памяти. Таким образом, ядро ​​убивает его (oom-killer - убийца нехватки памяти ядра) для поддержания стабильности системы.

Это похоже на VPS - так? Какие? Ошибки OOM, как правило, встречаются редко на физических машинах с достаточным (1 ГБ +) ОЗУ и местом подкачки (не менее 2 ОЗУ).

3
ответ дан 2 August 2018 в 00:23

То, что происходит, просто, а почему нет (нужно больше информации).

php5-cgi начинает использовать много памяти в это время (это может быть утечка памяти или побочный эффект), настолько, что системе не хватит памяти. Таким образом, ядро ​​убивает его (oom-killer - убийца нехватки памяти ядра) для поддержания стабильности системы.

Это похоже на VPS - так? Какие? Ошибки OOM, как правило, встречаются редко на физических машинах с достаточным (1 ГБ +) ОЗУ и местом подкачки (не менее 2 ОЗУ).

3
ответ дан 4 August 2018 в 15:52

То, что происходит, просто, а почему нет (нужно больше информации).

php5-cgi начинает использовать много памяти в это время (может быть утечка памяти или побочный эффект), настолько, что системе не хватит памяти. Таким образом, ядро ​​убивает его (oom-killer - убийца нехватки памяти ядра) для поддержания стабильности системы.

Это похоже на VPS - так? Какие? Ошибки OOM, как правило, встречаются редко на физических машинах с достаточным (1 ГБ +) ОЗУ и местом подкачки (не менее 2 ОЗУ).

3
ответ дан 6 August 2018 в 00:30

То, что происходит, просто, а почему нет (нужно больше информации).

php5-cgi начинает использовать много памяти в это время (это может быть утечка памяти или побочный эффект), настолько, что системе не хватит памяти. Таким образом, ядро ​​убивает его (oom-killer - убийца нехватки памяти ядра) для поддержания стабильности системы.

Это похоже на VPS - так? Какие? Ошибки OOM, как правило, встречаются редко на физических машинах с достаточным (1 ГБ +) ОЗУ и местом подкачки (не менее 2 ОЗУ).

3
ответ дан 7 August 2018 в 17:54

То, что происходит, просто, а почему нет (нужно больше информации).

php5-cgi начинает использовать много памяти в это время (может быть утечка памяти или побочный эффект), настолько, что системе не хватит памяти. Таким образом, ядро ​​убивает его (oom-killer - убийца нехватки памяти ядра) для поддержания стабильности системы.

Это похоже на VPS - так? Какие? Ошибки OOM, как правило, встречаются редко на физических машинах с достаточным (1 ГБ +) ОЗУ и местом подкачки (не менее 2 ОЗУ).

3
ответ дан 10 August 2018 в 06:45

То, что происходит, просто, а почему нет (нужно больше информации).

php5-cgi начинает использовать много памяти в это время (это может быть утечка памяти или побочный эффект), настолько, что системе не хватит памяти. Таким образом, ядро ​​убивает его (oom-killer - убийца нехватки памяти ядра) для поддержания стабильности системы.

Это похоже на VPS - так? Какие? Ошибки OOM, как правило, встречаются редко на физических машинах с достаточным (1 ГБ +) ОЗУ и местом подкачки (не менее 2 ОЗУ).

3
ответ дан 15 August 2018 в 18:38
  • 1
    Это выделенный сервер Kimsufi 2G: kimsufi.co.uk . Объем оперативной памяти составляет 2 ГБ, а процессор - Intel Atom 1,20+ ГГц. – Zbyněk Nedoma 9 July 2012 в 17:19
  • 2
    @ ZbyněkNedoma: спасибо, через несколько часов я подробно рассмотрю ваш журнал и постараюсь выяснить больше. Что делает php5-cgi перед 00:50? Что-то вызывает это ... – ish 9 July 2012 в 17:21
  • 3
    В системном журнале я нашел это: drwebd.real: Loading /var/drweb/bases/drwnasty.vdb - Ok, virus records: 28348 drwebd.real: Total virus records: 3473166 drwebd.real: Key file: /opt/drweb/drweb32.key - Key file was not found! (No such file or directory) drwebd.real: A path to a valid license key file was not specified. drwebd.real: Daemon is enabled for protecting 0 e-mails: drwebd.real: Daemon is installed, active interfaces: /var/drweb/run/.daemon 127.0.0.1:3000 CRON[20081]: (root) CMD (/usr/local/rtm/bin/rtm 8 > /dev/null 2> /dev/null) ..... Repeat this about 20 times – Zbyněk Nedoma 9 July 2012 в 18:01

Другие вопросы по тегам:

Похожие вопросы: