У меня была обычная проблема, заключающаяся в невозможности перезапустить httpd из-за большого количества заблокированных семафоров. После очистки и перезапуска httpd я также удвоил семафоры.
Однако я полагаю, что в каком-то процессе Apache есть утечка памяти, и он не освобождает их, поэтому я все равно столкнусь с проблемой, но позже.
пример ipcs -s:
------ Semaphore Arrays --------
key semid owner perms nsems
0x00000000 13467648 apache 600 1
0x00000000 13697025 apache 600 1
0x00000000 13729794 apache 600 1
0x00000000 13762563 apache 600 1
0x00000000 13795332 apache 600 1
0x00000000 14057477 apache 600 1
0x00000000 14123014 apache 600 1
0x00000000 14155783 apache 600 1
0x00000000 14188552 apache 600 1
0x00000000 14221321 apache 600 1
0x00000000 14254090 apache 600 1
Итак, давайте проследим, какой процесс управлял этими ipcs -s -i 13697025:
Semaphore Array semid=13697025
uid=48 gid=48 cuid=0 cgid=0
mode=0600, access_perms=0600
nsems = 1
otime = Not set
ctime = Thu Jul 11 03:41:01 2019
semnum value ncount zcount pid
0 1 0 0 18395
И напоследок что соответствует pid ps --pid 18395:
PID TTY TIME CMD
Правильно ли я прочитал: второй семафор в списке принадлежит процессу, который уже умер и не очистился?
Например, выполнение процесса со вторым последним в списке показывает, что он действительно принадлежит запущенному процессу:
PID TTY TIME CMD
22331 ? 00:03:42 httpd
Очевидно, что они принадлежат Apache, но как лучше всего устранить причину этого? У нас есть более 50 виртуальных хостов, есть ли способ зарегистрировать фактический запрос сервера и отследить его до порожденного процесса и т. Д.?
У меня есть основания полагать, что это php-sqlsrv.x86_64 расширение или что-то связанное с ним из-за временного соотношения между тем, когда это было настроено, и тем, когда возникла проблема. У меня есть возможность откатиться, но я просто хочу узнать, как углубиться в отладку, возможно, даже отправить исправление для ошибки.