pthread_mutex_lock 문제 디버깅 및 분석

pthread_mutex_lock 문제 디버깅 및 분석

저는 최근 Linux 뮤텍스, 특히 MySQL, memcache 및 APCu와 관련된 몇 가지 핵심 문제에 직면했습니다.

예:

  • SQLSTATE[HY000]: 일반 오류: 1205 잠금 대기 시간 초과, 트랜잭션 재시작 시도: INSERT INTO
  • 구리 구리:https://github.com/krakjoe/apcu/issues/416
  • Memcache OOM: 메모리 부족과 관련된 것

Linux에 대한 나의 지식은 매우 기본적이고 제한적입니다. 나는 뮤텍스가 두 개 이상의 동시 프로세스가 충돌하거나 경쟁 조건을 유발하지 않도록 보장하는 메커니즘이라는 것을 알고 있으며 괜찮습니다.

  • MySQL의 경우 MySQL이 일부 InnoDB 테이블에 잠금을 설정했다는 것을 알고 있으므로 다시 시작하면 문제가 해결되었습니다. 하지만 내가 이해하지 못하는 것은 해당 잠금을 유지하는 동안 어떤 프로세스가 종료되는지입니다. 누가, 어떤 이유로 죽였는지, 그리고 그 장면을 촉발한 코드는 무엇이었나요? 저는 MySQL 8을 사용하고 있는데 Performance_schema.data_lock_waits를 확인할 수 있을까요? 하지만 다음에 취해야 할 조치는 무엇입니까?
  • APCu의 경우: 실행 중인 PHP 프로세스에서 strace를 실행했고, FUTEX_WAIT를 얻었고, GDB를 실행했는데, apcu_inc가 pthread_rwlock_wrlock에서 멈췄습니다. APCu를 비활성화하면 문제가 해결되었고 업그레이드도 완료되었습니다. 이는 이 문제를 더 자세히 조사할 수 있는 기회였지만 프로덕션 서버에서 이 문제를 신속하게 해결해야 했기 때문에 그럴 수 없었습니다. 재현할 수 있습니다. APCu를 사용하는 패키지가 많고, 그렇지 않은 경우에도 pthread_mutex_lock을 사용하는 패키지가 많기 때문에 관련 내용을 제거할 수는 없습니다.
  • memcached의 경우: 매우 오래된 버전(2012 버전)을 사용하고 있어 계속해서 충돌이 발생합니다. 릴리스 노트를 보면 Memcache가 이와 관련하여 몇 가지 어려움을 겪고 있다는 것을 알고 있습니다. 인수 및 개요와 관련된 다양한 문제를 조사하고 이를 추가로 조사하는 데 도움이 될 수 있는 것이 있는지 알아볼 계획입니다. "Hey, I have OOM"과 같은 공개 질문을 피할 수 없습니다. 나는 내 일을 해야 하고 최소한 무언가를 공유하거나 재현할 수 있어야 합니다.

나는 이것으로부터 두 가지 시나리오를 얻습니다.

  • 실행 프로세스: 나는 이 문제를 처리할 수 있다고 생각했습니다. 코드를 자세히 살펴보고 다른 사람들도 이 문제를 겪었기를 바랍니다.
  • 종료된 프로세스: 이 문제를 어떻게 처리해야 할지 모르겠습니다. MySQL과 Memcache에 관한 한, 누가, 어떤 이유로 이들을 죽였습니까? 코드를 추적할 수 있나요? 이를 모니터링하려면 몇 가지 도구가 필요합니까? 무슨 일이 일어나고 있는지 어떻게 알아낼 수 있나요? 일부 장치 잠금이나 I/O를 살펴봐야 합니까?

이 문제를 어떻게 처리합니까?

관련 정보