В каком состоянии находится процесс при выполнении pthread _мьютекса ()
Это просто сообщение информационного -уровня. Количество серверных процессов меняется вместе с трафиком, поэтому генерируются новые. Единственное, у вас был спайк, так как ваши 20 MinSpareServers израсходовались быстрее, чем могли стартовать новые. (Я думаю, что браузеры будут регулярно открывать до 8 подключений для загрузки изображений и т. д. параллельно. )140 дочерних элементов на оборудовании такого размера не кажутся чрезмерными, вы, вероятно, можете увеличить до 200 -иш, прежде чем система начнет подкачку, именно при подкачке вам действительно нужно беспокоиться.
Вы можете попробовать поднять MinSpare до 30, но реальное увеличение количества подключений будет происходить за счет отказа от prefork -mpm, что может быть или не быть возможным в вашей настройке, сказать невозможно. (Вероятным фактором является то, что мод _php означает, что вы не можете, вам нужно переключиться на php -fpm или что-то в этом роде, что все возможно,но далеко за рамками «я не могу коснуться настройки клиента».)
Что ж, давайте узнаем:
#include <pthread.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
int main ()
{
pthread_mutex_t mtx;
pid_t pid;
pthread_mutex_init (&mtx, NULL);
pid = getpid();
printf ("pid : %d\n", pid);
pthread_mutex_lock (&mtx);
// Double lock. This results in a dead-lock
pthread_mutex_lock (&mtx);
pthread_mutex_destroy (&mtx);
}
Компилировать с помощью:
gcc -lpthread -o prog prog.c
А потом бегом:
./prog
pid : 23537
(Это pid в моем конкретном случае. Ваш забег приведет к другому)
Теперь выясним состояние этого процесса:
ps aux | grep 23537
user 23537 0.0 0.0 6448 840 pts/4 S+ 16:29 0:00./prog
S+ — это состояние процесса.
Согласно справочной странице
PROCESS STATE CODES
Here are the different values that the s, stat and state output specifiers (header "STAT" or "S") will display to describe the state of a
process:
D uninterruptible sleep (usually IO)
R running or runnable (on run queue)
S interruptible sleep (waiting for an event to complete)
T stopped by job control signal
t stopped by debugger during the tracing
W paging (not valid since the 2.6.xx kernel)
X dead (should never be seen)
Z defunct ("zombie") process, terminated but not reaped by its parent
For BSD formats and when the stat keyword is used, additional characters may be displayed:
< high-priority (not nice to other users)
N low-priority (nice to other users)
L has pages locked into memory (for real-time and custom IO)
s is a session leader
l is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
+ is in the foreground process group
Итак, это прерываемый сон (ожидание завершения события )в группе процессов переднего плана
Что касается вашего второго вопроса :, когда поток пытается получить уже заблокированный мьютекс, ядро удаляет этот поток из ЦП и сохраняет его в очереди. Когда владелец снимает блокировку, ядро проверяет, есть ли в очереди потоки, и пробуждает их (, возможно, ).
Это отличается от спин-блокировки. Спин-блокировка будет чем-то похожим на:
int lock = 1;
// 1 means locked, 0 means unlocked
while (lock) {};
// If we are here, it means the lock somehow changed to 0
lock = 1;
// We set it to one again to avoid another thread taking it
Но эта реализация не атомарна. Ядро предоставляет некоторые средства для выполнения этого атомарно.