Как диагностировать ошибку сегментации на производственном сервере CentOS?

Question

У нас есть пара PHP сценариев, которые можно запустить из CLI. На выполнение обоих может потребоваться несколько часов, и исторический прогон в порядке (иногда требуется увеличение пределов памяти). Однако на нашем производственном сервере сценарии через относительно короткий промежуток времени перестают работать с ошибкой segfault:

/home/*******/bin/runlive: line 3:  9558 Segmentation fault      php 
 $HOME/********/sites/live/index.php" $*

(runlive - просто устанавливает путь). Мы попытались запустить это на другой сервер с теми же данными базы данных и кодовой базой и не получает ту же ошибку Мы попытались переместить производственный сервер на новую виртуальную машину, чтобы в качестве причины использовать оборудование со скидкой, но это не помогло решить проблему. Мы попытались использовать утилиту catchsegv для вывода информации о segfault:

sudo /usr/bin/catchsegv runlive [script name] > catchsegv.txt

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

Любые идеи о том, как это диагностировать, приветствуются.

Answer 1

Любые идеи о том, как диагностировать это

Существует несколько возможностей:

1. Плохое оборудование
2. Плохое программное обеспечение

Плохое программное обеспечение может быть разделено на:

1. Плохое сочетание библиотек (неправильное сочетание версий, сервер с ошибками и т. Д. c.)
2. Плохое окружение (например, конкретное имя хоста или пути установки)

Вы хотите использовать разделяй и властвуй подход для устранения возможностей.

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

Возможно, вы захотите сделать следующее:

Создайте другую виртуальную машину (предпочтительно в месте, которое, как вы знаете, работает на другой физической машине), с точно одинаковыми версиями всех установленных пакетов с использованием доверенного источника (не просто копируйте пакеты с исходного компьютера).

Проверьте погоду, сбои по-прежнему воспроизводятся. Если они это сделают, ваш исходный сервер, вероятно, не powned, и имя хоста, вероятно, не имеет значения.

Если сбои не воспроизводятся, вы устранили 2.1 (плохая комбинация версий), и теперь нужно чтобы изучить различия между двумя машинами с помощью тонкой расчески.

Продолжайте разделять проблему, пока не найдете причину root.

или вы можете взять нижнюю подход up: запустите двоичный файл php в отладчике, воспроизведите cra sh, найдите отчеты об ошибках восходящего потока с аналогичной трассировкой стека, примените исправления для этих ошибок (если вы обнаружите такие ошибки) и т. д. c.