Я думаю, вы правы в своей логике, что stat curr_connections
- это количество текущих соединений.
curr_connections - количество открытых соединений с этим сервером Memcached, должно быть одинаковым значением на всех серверах во время нормальной работы. Это что-то вроде подсчета строк результата mySQL "SHOW PROCESSLIST".
Источник: Статистика Memcached (команда stats)
Когда я настраивал memcached
, я заметил, что он всегда поддерживал 10 как наименьшее количество curr_connections
.
$ echo stats | nc localhost 11211 | grep curr_conn
STAT curr_connections 10
Если вы запустите memcached
в режиме verbose, вы увидите следующий вывод:
$ memcached -vv
...
<26 server listening (auto-negotiate)
<27 server listening (auto-negotiate)
<28 send buffer was 212992, now 268435456
<28 server listening (udp)
<28 server listening (udp)
<28 server listening (udp)
<29 send buffer was 212992, now 268435456
<28 server listening (udp)
<29 server listening (udp)
<29 server listening (udp)
<29 server listening (udp)
<29 server listening (udp)
Если вы подсчитаете количество слушающих серверов (8) + 2 сервера (auto-negotiated), вы поймете, почему для начала есть 10 базовых серверов, по крайней мере, так я подумал сначала. Но вам нужно копнуть глубже, чтобы лучше понять, что происходит.
Похоже, что memcached
является многопоточным, и поэтому вывод, на который вы обратили внимание, на самом деле не является подсчетом соединений.
Вывод ps -eLf
показывает потоки:
$ ps -eLf | grep memc
saml 20036 4393 20036 0 6 20:07 pts/7 00:00:00 memcached -vv
saml 20036 4393 20037 0 6 20:07 pts/7 00:00:00 memcached -vv
saml 20036 4393 20038 0 6 20:07 pts/7 00:00:00 memcached -vv
saml 20036 4393 20039 0 6 20:07 pts/7 00:00:00 memcached -vv
saml 20036 4393 20040 0 6 20:07 pts/7 00:00:00 memcached -vv
saml 20036 4393 20041 0 6 20:07 pts/7 00:00:00 memcached -vv
Есть один главный узел и 5 рабочих потоков.
Вот как выглядит вывод lsof
, когда я сделал 3 подключения к memcached
, используя тот же метод, что и вы, telnet localhost 11211
.
Таким образом, похоже, что каждый поток поддерживает соединение (или ссылку на каждое соединение) по мере того, как они создаются и остаются открытыми. Как только telnet
соединения закрываются, они исчезают из этого списка.
Итак, если вы хотите подсчитать количество соединений, вы можете либо вычесть 10 из результата curr_connections
, либо выполнить lsof
и подсчитать количество соединений, связанных с основным PID. Обратите внимание на этот результат:
$ lsof |grep memcac | grep IPv
memcached 20036 saml 26u IPv4 7833065 0t0 TCP *:memcache (LISTEN)
memcached 20036 saml 27u IPv6 7833066 0t0 TCP *:memcache (LISTEN)
memcached 20036 saml 28u IPv4 7833069 0t0 UDP *:memcache
memcached 20036 saml 29u IPv6 7833070 0t0 UDP *:memcache
memcached 20036 saml 30u IPv6 7962078 0t0 TCP localhost:memcache->localhost:38728 (ESTABLISHED)
Последняя строка - это активное соединение. Поэтому мы можем посчитать их следующим образом:
$ lsof -p $(pgrep memcached) | grep "memcache->" | wc -l
1
Чтобы еще больше упростить пример, давайте запустим memcached
и заставим его слушать только один адрес IPv4, 192.168.1.20. В приведенных выше примерах мы запускали memcached
на всех интерфейсах и подключались к нему, используя localhost
, поэтому давайте посмотрим еще раз.
$ memcached -vv -l 192.168.1.20
...
<26 server listening (auto-negotiate)
<27 send buffer was 212992, now 268435456
<27 server listening (udp)
<27 server listening (udp)
<27 server listening (udp)
<27 server listening (udp)
Заметили, что мы получаем только на 1/2 больше? Ранее у нас было 2 автосогласованных сервера и 8 UDP, в этот раз у нас 1 авто и 4 UDP. Почему? Ну, мы сказали memcached
слушать только интерфейс IPv4, ранее он слушал все, IPv4 и localhost. Мы можем убедиться в этом, попытавшись подключиться к серверу на localhost:
$ telnet localhost 11211
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Видите, мы не можем подключиться. Но мы можем, используя адрес IPv4:
$ telnet 192.168.1.20 11211
Trying 192.168.1.20...
Connected to 192.168.1.20.
Escape character is '^]'.
Что теперь говорит stats?
STAT curr_connections 5
Видите? curr_connections
показывает число 5 (1 auto + 4 UDP).
Почему мы используем 4 UDP? Похоже, что это настройка по умолчанию в memcached
. Вы можете увидеть настройки с помощью команды stats settings, когда вы
telnet` к серверу:
stats settings
STAT maxbytes 67108864
STAT maxconns 1024
STAT tcpport 11211
STAT udpport 11211
STAT inter 192.168.1.20
STAT verbosity 2
...
STAT num_threads 4
STAT num_threads_per_udp 4
...
Можем ли мы изменить это значение? Конечно, это -t #
переключатель на memcached
.
$ memcached -vv -l 192.168.1.20 -t 1
...
<11 server listening (auto-negotiate)
<12 send buffer was 212992, now 268435456
<12 server listening (udp)
Итак, теперь у нас есть только главный слушатель (auto) и 1 поток UDP. Если мы проверим stats
сейчас:
STAT curr_connections 2
Кстати, мы не можем установить количество потоков на 0.
$ memcached -vv -l 192.168.1.20 -t 0
Number of threads must be greater than 0
Таким образом, самое низкое значение, которое мы можем получить от curr_connections
- 2. Если мы откроем 6 telnets (5 от нас самих - greeneggs и 1 от другого удаленного сервера под названием skinner), мы увидим следующее в нашем lsof
выводе:
$ lsof -p $(pgrep memcached) | grep ":memcache"
memcached 24949 saml 11u IPv4 847365 0t0 TCP greeneggs.bubba.net:memcache (LISTEN)
memcached 24949 saml 12u IPv4 847366 0t0 UDP greeneggs.bubba.net:memcache
memcached 24949 saml 13u IPv4 855914 0t0 TCP greeneggs.bubba.net:memcache->greeneggs.bubba.net:48273 (ESTABLISHED)
memcached 24949 saml 14u IPv4 872538 0t0 TCP greeneggs.bubba.net:memcache->skinner.bubba.net:41352 (ESTABLISHED)
memcached 24949 saml 15u IPv4 855975 0t0 TCP greeneggs.bubba.net:memcache->greeneggs.bubba.net:48298 (ESTABLISHED)
memcached 24949 saml 16u IPv4 855992 0t0 TCP greeneggs.bubba.net:memcache->greeneggs.bubba.net:48305 (ESTABLISHED)
memcached 24949 saml 17u IPv4 859065 0t0 TCP greeneggs.bubba.net:memcache->greeneggs.bubba.net:48316 (ESTABLISHED)
memcached 24949 saml 18u IPv4 859077 0t0 TCP greeneggs.bubba.net:memcache->greeneggs.bubba.net:48326 (ESTABLISHED)
Итак, у нас все еще есть auto + 1 UDP и 6 других соединений. Наша команда stats
показывает следующее:
STAT curr_connections 8
Так что ничего удивительного.
Попробуйте изменить каталог, в котором вы пишете out.txt
. Например, измените эту команду на эту:
$ grep -v "Chapter" *.txt | grep -nE -C1 " leaves? " > /tmp/out.txt
Здесь вы можете увидеть, что происходит, когда вы включаете подробный вывод в вашей оболочке Bash.
$ set -x
$ grep -v "Chapter" *.txt | grep -nE -C1 " leaves? " > out.txt
+ grep --color=auto -nE -C1 ' leaves? '
+ grep --color=auto -v Chapter file01.txt file02.txt file03.txt file04.txt file05.txt file06.txt file07.txt file08.txt file09.txt file10.txt out.txt
Обратите внимание, что он берет аргумент *.txt
и расширяет его, включая файл out.txt
. Таким образом, вы буквально анализируете этот файл, когда записываете в него.
Если вы думаете о том, что делает оболочка, когда вывод одной команды передается в следующую, это имеет смысл. Оболочка анализирует команды, которые вы только что ей дали, ищет каналы(|
). Когда он сталкивается с ними, он должен запускать команды справа, чтобы настроить перенаправление STDIN/STDOUT между командами, происходящими внутри каналов.
Вы можете использовать команду sleep
, чтобы увидеть, как оболочка анализирует вещи по мере добавления дополнительных каналов:
$ sleep 0.1 | sleep 0.2 | sleep 0.3 | sleep 0.4
+ sleep 0.2
+ sleep 0.3
+ sleep 0.4
+ sleep 0.1
$ sleep 0.1 | sleep 0.2 | sleep 0.3 | sleep 0.4 | sleep 0.5
+ sleep 0.2
+ sleep 0.3
+ sleep 0.4
+ sleep 0.5
+ sleep 0.1
Выполнение этого с echo
+ запись в файл также показывает порядок через доступ к файлу и команду stat
:
$ echo "1" > file1 | echo "2" > file2 | echo "3" > file3 | echo "4" > file4
+ echo 2
+ echo 3
+ echo 4
+ echo 1
$ stat file* | grep -E "File|Access: [[:digit:]]+"
+ grep --color=auto -E 'File|Access: [[:digit:]]+'
+ stat file1 file2 file3 file4
File: ‘file1’
Access: 2018-08-11 23:55:20.868220474 -0400
File: ‘file2’
Access: 2018-08-11 23:55:20.865220576 -0400
File: ‘file3’
Access: 2018-08-11 23:55:20.866220542 -0400
File: ‘file4’
Access: 2018-08-11 23:55:20.867220508 -0400