Linux error 11 resource temporarily unavailable

Ошибка NGINX — 11: Resource temporarily unavailable — На связке NGINX + PHP-FPM через unix socket

Настроена связка NGINX + PHP-FPM. PHP-FPM слушает обращения работает через unix socket:

listen.owner = php listen.group = php listen.mode = 666 listen = /var/run/php-fpm.sock listen.backlog = 65535

Операционная система CentOS 6.5

NGINX настроен принимать входящие соединения на адресе test.local и передавать их на PHP-FPM

Параметры в fcgi-as.fconf всегда отдают все обращения файлу index.php

В файле index.php прописан маленький скрипт для теста:

Для тестирования производительности используется программа OpenLoad — http://openwebload.sourceforge.net/

Программа собрана из исходников, для сборки пришлось её немного пропатчить, так как она во первых не компилировалась, а во вторых нельзя было указать дополнительные параметры для gcc через configure.

В файле /src/tmplchunk.h меняем строку:

virtual int CTmplChunk::Verify(const char*& pos, const char* parm);

virtual int Verify(const char*& pos, const char* parm);

После выполнения configure в файле /src/Makefile меняем строку:

CXXFLAGS = -g -O3 -march=native

Этого можно и не делать, но тогда программа немного подтормаживает и выполняет на 3-5% запросов меньше.

Важно: Не пытайтесь использовать openload или любую другую программу для тестирования Вашего сервера на windows, на этой OS Вы скорее упретесь в производительность Вашей windows машины чем в производительность Вашего сервера, а результаты не будут достоверными.

Выполняем компиляцию программы

configure [Патчим файлы] make make install

И начинаем тестирование. Параметры программы:

openload [опции] URL [кол-во клиентов] ОПЦИИ: -t - Режим тестирования, в этом режиме не будет производиться тестирования производительности, а вместо этого будет отображен полный ответ от сервера включая заголовки. Это может быть полезно если Вы хотите проверить правильность введенного URL. -h header value - Дополнить каждый запрос заголовком header со значением value -h User-Agent "MSIE 5.0" -l time - время time в секундах в течении которого выполнять тестирование -o outputmode - режим вывода результата, в данный момент поддерживается только csv ОПИСАНИЕ РЕЗУЛЬТАТА: MaTps - Скользящее среднее значение TPS за последние 20 секунд. Tps - Кол-во запросов которые клиенты успели выполнить за последнюю секунду Resp Time - Серднее время ответа по всем запросам за последнюю секунду Err - Процент запросов которые были выполнены с ошибкой (код ответа HTTP отличный от 200) Count - Общее кол-во выполненных запросов с начала тестирования Total TPS - Среднее значение TPS за все тестирование Avg. Response Time - Среднее время ответа за все тестирование в секундах Max. Response Time - Максимальное время ответа за все тестирование в секундах

openload -l 1 http://test.local 1

URL: http://test.local:80/ Clients: 1 Time Limit: 1 sec. MaTps 1060.00, Tps 1060.00, Resp Time 0.001, Err 0%, Count 1060 Total TPS: 1058.94 Avg. Response time: 0.001 sec. Max Response time: 0.009 sec Total Requests: 1060 Total Errors: 0

openload -l 1 http://test.local 200

URL: http://test.local:80/ Clients: 200 Time Limit: 1 sec. MaTps 1613.00, Tps 1613.00, Resp Time 0.120, Err 13%, Count 1613 Total TPS: 1531.81 Avg. Response time: 0.120 sec. Max Response time: 0.320 sec Total Requests: 1613 Total Errors: 214

В логе nginx видим строчки:

2014/10/17 12:52:34 [error] 8740#0: *720283 connect() to unix:/var/run/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream,

Проиходит это потому что операционная система отвергает попытки nginx подключиться к unix сокету.

Причина либо превышено максимальное кол-во соединений к сокету либо максимальное кол-во не обработанных соединений к сокету.

net.core.somaxconn = 128 net.core.netdev_max_backlog = 200

Из-за них и происходит ошибка, так как максимальное кол-во соединений 128 а максимум не обработанных 200

Меняем лимиты, в файл /etc/sysctl.conf прописываем строки

net.core.somaxconn = 20000 net.core.netdev_max_backlog = 65535

Запускаем наше тестирование:

openload -l 1 http://test.local 200

URL: http://test.local:80/ Clients: 200 Time Limit: 1 sec. MaTps 1423.00, Tps 1423.00, Resp Time 0.133, Err 0%, Count 1423 Total TPS: 1421.58 Avg. Response time: 0.133 sec. Max Response time: 0.276 sec Total Requests: 1423 Total Errors: 0

Вот и все, проблема решена, а заодно мы получили замечательную утилиту openload для последующего тестирования и оптимизации производительности нашего сервера.

Источник

Ошибка NGINX — 11: Resource temporarily unavailable — На связке NGINX + PHP-FPM через unix socket

Настроена связка NGINX + PHP-FPM. PHP-FPM слушает обращения работает через unix socket:

Операционная система CentOS 6.5

NGINX настроен принимать входящие соединения на адресе test.local и передавать их на PHP-FPM

Параметры в fcgi-as.fconf всегда отдают все обращения файлу index.php

В файле index.php прописан маленький скрипт для теста:

Для тестирования производительности используется программа OpenLoad — http://openwebload.sourceforge.net/

Программа собрана из исходников, для сборки пришлось её немного пропатчить, так как она во первых не компилировалась, а во вторых нельзя было указать дополнительные параметры для gcc через configure.

В файле /src/tmplchunk.h меняем строку:

После выполнения configure в файле /src/Makefile меняем строку:

Этого можно и не делать, но тогда программа немного подтормаживает и выполняет на 3-5% запросов меньше.

Важно: Не пытайтесь использовать openload или любую другую программу для тестирования Вашего сервера на windows, на этой OS Вы скорее упретесь в производительность Вашей windows машины чем в производительность Вашего сервера, а результаты не будут достоверными.

Выполняем компиляцию программы

Источник

How To Fix `Could not get lock /var/lib/dpkg/lock — open (11 Resource temporarily unavailable)` Errors

I’ve been getting a lot of «Could not get lock /var/lib/dpkg/lock» errors when»Could not get lock /var/lib/dpkg/lock — open (11 Resource temporarily unavailable)» trying to install or upgrade packages from the command line on Ubuntu virtual machines lately, so I thought I’d make a post about how you can get rid of such issues.

This is the complete error message:

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable) E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?

[[Edit]] For newer Ubuntu releases, this message has changed, and it now shows which process is holding the «/var/lib/dpkg/lock-frontend», like this:

Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 251486 (apt)

Just like the message says, this could happen if another process is using /var/lib/dpkg/lock . So the first thing to do if you encounter this error is to make sure you close package managers such as Synaptic, etc. Also check if you have other open terminals that are currently running an install / upgrade procedure and wait for those processes to finish. If you’re using a newer Ubuntu, the message itself will tell you which process is holding the «/var/lib/dpkg/lock» / «/var/lib/dpkg/lock-frontend».

If no processes are using /var/lib/dpkg/lock , the next step is to. wait. In some cases, this is enough to fix such «Could not get lock /var/lib/dpkg/lock» and «Could not get lock /var/lib/dpkg/lock-frontend» errors.

Another potential way to get around this issue is to reboot the system and see if this still occurs.

There are cases though in which the solutions mentioned above may not be enough. For such cases, here’s what you can do.

Only use this if nothing else worked! Using the commands below may result in broken packages / corruption. Use them at your own risk!

If nothing else worked (from my experience, this usually happens if the system was forcefully shut down or rebooted while installing or upgrading packages, e.g. due to a power outage), you can remove the apt lock / lock-frontend file and see if that fixes the issue on your Ubuntu / Debian / Linux Mint (and any system that uses APT) system:

sudo rm /var/lib/apt/lists/lock
sudo rm /var/lib/apt/lists/lock-frontend

If you’re still getting errors about either the apt cache lock ( /var/cache/apt/archives/lock ) or the dpkg lock ( /var/lib/dpkg/lock ), you can remove them:

sudo rm /var/cache/apt/archives/lock sudo rm /var/lib/dpkg/lock

A package reconfiguration may also be needed after this, as well as fixing any potentially broken packages:

sudo dpkg --configure -a sudo apt install -f

In some rare cases you may see an error like the one below, after trying to run sudo dpkg —configure -a :

$ sudo dpkg --configure -a dpkg: error: parsing file '/var/lib/dpkg/updates/0004' near line 0: newline in field name '#padding'

In such cases, remove the offending file, then run the sudo dpkg —configure -a command again. In my example above, the file is /var/lib/dpkg/updates/0004 (this may be different in your case!) so to remove it and reconfigure dpkg, one would need to use:

sudo rm /var/lib/dpkg/updates/0004 sudo dpkg --configure -a

Hopefully after running these commands you should stop getting the «Could not get lock /var/lib/dpkg/lock — open (11 Resource temporarily unavailable)» and «Could not get lock /var/lib/dpkg/lock-frontend — open (11 Resource temporarily unavailable)» errors.

Edit: one major reason for this error reoccurring seems to be the fact that Ubuntu enables unattended updates by default, and either an upgrade is currently in progress when you’re seeing this error (in which case you should wait until the upgrade is performed successfully!), or an upgrade failed, in which case you’re left with this error until you fix it. You could disable automatic (unattended) upgrades, see: How To Stop Installing Updates Automatically On Ubuntu Or Debian (Unattended Upgrades).

Источник