글을 게시한 후 페이지가 충돌하는 LiteSpeed 프로세스

저는 아직 확실한 해결책을 찾지 못한 문제를 한동안 해결하고 있습니다.

문제는 게시물을 게시한 직후 CPU 사용량이 급증하고 프로세스 수가 급증하여 사이트에 장시간 접속할 수 없게 된다는 것입니다.

이는 심각한 문제인데, 구독자가 새 발행물에 대한 알림을 받게 되는데 페이지가 해결되지 않아 읽을 수 없을 뿐만 아니라 페이지가 자주 다운되는 것이 포지셔닝에 어떤 의미가 있는지 알 수 없기 때문입니다.

시간이 지나면 시스템이 결국 프로세스를 종료하지만 그렇게 되려면 몇 시간이 걸릴 수 있습니다.

cPanel을 사용하는 경우 일반적으로 다음과 같은 메시지가 포함된 이메일을 받게 됩니다:

(Cron Daemon)
/bin/sh: line 1: 30255 Killed                  /usr/local/bin/php /home/user/public_html/wp-cron.php >> /home/user/public_html/wp-cron.log 2>&1

wp-config.php에서 DISABLE_WP_CRON이 활성화되어 있는데도 cPanel에서 "Killed" 메시지가 계속 수신되면 wp-cron.php를 실행하려는 다른 프로세스 또는 구성(아직 발견하지 못한)이 있으며 리소스(메모리, CPU 등) 과다 소비로 인해 시스템이 이를 종료하고 있다는 의미입니다.

오늘은 좀 더 자세히 조사하고 CPU 소비량을 모니터링했습니다. 이를 위해 브라우저의 터미널을 사용하여 cPanel의 LucusHost에서 제공하는 SSH 및 WP-CLI 액세스를 사용했습니다.

호스팅에서 허용하는 경우 액세스하려면 cPanel의 고급/터미널로 이동해야 합니다. 블로그 파일이 public_html 폴더에 있는 경우 다음과 같이 액세스해야 합니다:

cd public_html

그런 다음 실행 중인 프로세스를 확인하려면 다음과 같이 입력합니다.

top

다음과 같은 내용이 표시될 것입니다:

제 경우에는 CPU를 완전히 잡아먹는 lsphp 프로세스의 눈사태를 발견했습니다.

워드프레스 관리 영역만 열면 몇 초 후에 닫히는 4~5개의 LiteSpeed 프로세스(lsphp)를 볼 수 있습니다. 이는 정상적인 현상이며, LiteSpeed의 lsphp 프로세스는 PHP 연결을 효율적으로 처리하기 위한 아키텍처의 일부입니다.

그러나 새 글을 게시한 후(때로는 이미 게시된 글을 편집하는 것만으로도 충분할 때도 있음) 이러한 프로세스가 수와 CPU 사용량 모두에서 트리거되고 해제되지 않아 사이트가 종료되면 뭔가 잘못된 것입니다.

페이지 차단을 해제하는 첫 번째 응급 조치는 차단을 유발하는 문제를 해결하지는 못하지만 사이트에 다시 액세스할 수 있는 "멈춘" 프로세스를 종료하는 것입니다.

pkill -u TuNombreDeUsuario lsphp

원하는 경우 해당 프로세스의 PID를 사용하여 특정 프로세스를 종료할 수 있지만, 많은 프로세스가 짧은 간격으로 닫히고 열리므로 큰 도움이 되지 않을 수 있습니다.

# Detiene procesos con alto %CPU (ejemplo para detener el PID 7026)
kill -9 7026

일반적으로 기본적으로 LiteSpeed는 플러그인 구성과 사용 중인 옵션에 따라 이 네 가지 작업을 1분마다 실행합니다.

라이트스피드_태스크_이미지옵트_풀
라이트스피드_태스크_CCSS
라이트스피드_태스크_UCSS
라이트스피드_태스크_LQIP

처음 두 작업인 imgoptm_pull과 ccss는 때때로 시간 초과를 유발하는 무거운 작업이며(특히 공유 호스팅에서), ucss와 lqip는 가벼운 작업입니다.

그래서 제가 가장 먼저 시도한 것은 LiteSpeed에서 자동 Cron 관리를 비활성화하여 LiteSpeed의 자동 재생성을 차단하는 것입니다. 이를 위해 wp-config.php에 이것을 추가했습니다.

// Deshabilita la gestión automática de Cron en LiteSpeed
define('LITESPEED_DISABLE_CACHE_PURGE_CRON', true);
define('LITESPEED_DISABLE_AUTOUPDATE_CRON', true);

그런 다음 functions.php에 다음 함수를 추가하여 1분 간격을 강제로 제거하고 이러한 작업을 다른 시간에 분산하여 하루에 한 번으로 변경하여 과도한 CPU 소비를 방지할 수 있습니다. 예를 들어 블로그의 트래픽에 따라 오전과 같은 다른 시간대에 이 시간을 설정할 수 있습니다.

/**
 * Cambia la frecuencia de las tareas de LiteSpeed Cache de "cada minuto" a "una vez al día" a distintas horas".
 */
add_action('init', function() {
    // Eliminar el intervalo "litespeed_filter"
    add_filter('cron_schedules', function($schedules) {
        if (isset($schedules['litespeed_filter'])) {
            unset($schedules['litespeed_filter']);
        }
        return $schedules;
    }, 9999);

    // Reprogramar tareas con timestamps únicos
    $tasks = array(
        'litespeed_task_imgoptm_pull' => strtotime('tomorrow 00:30'),
        'litespeed_task_ccss'         => strtotime('today 20:00'),
        'litespeed_task_ucss'         => strtotime('tomorrow 00:00'),
        'litespeed_task_lqip'         => strtotime('tomorrow 04:00')
    );

    foreach ($tasks as $hook => $time) {
        if (wp_next_scheduled($hook)) {
            wp_unschedule_event(wp_next_scheduled($hook), $hook);
        }
        wp_schedule_event($time, 'daily', $hook);
    }
}, 9999);

이러한 변경 사항이 적용되면 고급 데이터베이스 클리너 프로 플러그인에 따라 이러한 변경 사항이 적용되고 있는지 확인합니다. Wp Crontrol에서 확인할 수도 있습니다.

기본 워드프레스 가상 크론을 사용하지 않는다고 가정하면 CPU 소비를 더욱 가볍게 하기 위해 새로운 크론이 추가되어 빈도를 30분으로 늘리고 플록과의 중복을 방지하며 서버 부하를 줄입니다.

*/30    *       *       *       * /usr/bin/flock -xn /tmp/wp-cron.lock /usr/local/bin/php /home/TuNombreDeUsuario/public_html/wp-cron.php > /dev/null 2>&1

이제 wp cron 스케줄 목록을 실행하면 litespeed_filter 또는 다른 필터가 60초마다 실행되지 않는 것을 확인할 수 있습니다.