Как отладить memc/memcached тайм-ауты с Nginx?

Это - то, как я сделал бы это:

Создайте систему тестирования с DB2 и сервером Пост-ГРЭС. Попробуйте миграцию (идеально с некоторыми реальными данными из одних из Ваших резервных копий). Удостоверьтесь, что это работает. Создайте сценарий, который автоматизирует процесс - и удостоверьтесь что работы, также.

Затем в день миграции, настраивает перенаправление к статической странице HTML, останавливают сервер, делают резервное копирование, запускают Ваш скрипт. Проверьте, что все пошло хорошо.

  • В противном случае восстановите резервное копирование.
  • Если да, запустите сервер.

Удостоверьтесь, что это работает, также.

  • Удалите перенаправление.
2
задан 4 September 2011 в 00:30
1 ответ

From the error log output it looks as if NGiNX is waiting for network communication both in attempts to setup new connections and get data back from old connections. You mentioned it happens both locally and remote so you say you ruled out networking. However even the local one is still using a TCP socket to connect right? Have you already checked that you aren't running out of mbufs on the BSD box:

# netstat -m
16387/4613/21000 mbufs in use (current/cache/total)
16385/3957/20342/25600 mbuf clusters in use (current/cache/total/max)
16384/2176 mbuf+clusters out of packet secondary zone in use (current/cache)
0/403/403/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
36866K/10679K/47546K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

If you see mbufs are the issue you need to update your loader.conf and reboot(sadly not a runtime tunable), from /boot/loader.conf:

kern.ipc.nmbclusters="128000"

If you don't see anything there that indicates total==max then you should probably start by confirming that nginx isn't to blame. I would probably do this by tcpduming the connection from nginx to memcached and verifying that nginx has indeed sent connection setups or requests when it claims its timing out waiting. If that works out then I'd probably start running ktrace on the memcached process for a few minutes while an error occurs and look through the kdump to see if there are system calls failing (like send or accepts).

1
ответ дан 3 December 2019 в 13:16

Теги

Похожие вопросы