Вывод контекста (-C) для grep создает большие файлы.

Я думаю, вы правы в своей логике, что 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

Но почему 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.

ss #1

Таким образом, похоже, что каждый поток поддерживает соединение (или ссылку на каждое соединение) по мере того, как они создаются и остаются открытыми. Как только 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

Но ваш вывод показывает IPv4 и IPv6, что с этим?

Чтобы еще больше упростить пример, давайте запустим 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?

Почему мы используем 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

Так что ничего удивительного.

1
12.08.2018, 06:17
1 ответ

Попробуйте изменить каталог, в котором вы пишете 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
3
27.01.2020, 23:23

Теги

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