Бармен: rsync wal архивирует некоторые файлы
Я архивирую файлы wal с сервера postgres через rsync, большую часть времени архивирование работает нормально и быстро, тест скорости соединения здесь: (это идет через Интернет)
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 9.30 MBytes 78.0 Mbits/sec 0 395 KBytes
[ 4] 1.00-2.00 sec 66.3 MBytes 556 Mbits/sec 14 1.05 MBytes
[ 4] 2.00-3.00 sec 75.0 MBytes 629 Mbits/sec 0 1.16 MBytes
[ 4] 3.00-4.00 sec 81.2 MBytes 682 Mbits/sec 0 1.24 MBytes
[ 4] 4.00-5.00 sec 86.2 MBytes 724 Mbits/sec 0 1.30 MBytes
[ 4] 5.00-6.00 sec 88.8 MBytes 744 Mbits/sec 0 1.34 MBytes
[ 4] 6.00-7.00 sec 91.2 MBytes 765 Mbits/sec 0 1.37 MBytes
[ 4] 7.00-8.00 sec 92.5 MBytes 776 Mbits/sec 0 1.38 MBytes
[ 4] 8.00-9.00 sec 93.8 MBytes 786 Mbits/sec 0 1.39 MBytes
[ 4] 9.00-10.00 sec 63.8 MBytes 535 Mbits/sec 22 535 KBytes
Таким образом, пропускной способности более чем достаточно.
Но для некоторых файлов WAL он просто ползет до медленного, и требуется 30-50 секунд , пока не будет передан файл размером 16 МБ, и я не понимая, где отлаживать / искать проблему.
Команда rsync выглядит так:
rsync -p --chmod=Fg+r,Fo+r --timeout 10 -e /usr/bin/ssh -i /var/lib/pgsql/.ssh/id_rsa -a pg_wal/000000080000A5500000005D barman@barman_host/data/database/pg/incoming/000000080000A5500000005D
Я посмотрел на rsync через strace на принимающей стороне, и кажется, что не приходили только пакеты от отправляющей стороны достаточно быстро. Я попытался перехватить файл через ssh и вывести его на свою консоль, что было завершено до передачи rsync. Я попытался переместить его в / dev / null, это было мгновенно.
Итак, я предполагаю, что исходный диск достаточно быстрый.
Я перенес большую часть файлов WAL (60 ГБ) с помощью одной команды rsync, которая также была быстро и в среднем 65 МБ / с, так что это говорит о том, что все работает нормально, но некоторые файлы работают медленно.
Что еще я могу посмотреть? Как я могу определить, связана ли проблема с отправляющей стороной, скоростью интернета, принимающей стороной, есть ли какие-то специальные журналы, которые я могу активировать на rsync? Могу ли я проверить время системных вызовов через strace?
ls -l 000000080000A578000000E8
-rw-------. 1 postgres postgres 16777216 Jul 19 07:32 000000080000A578000000E8
bash-4.2$ du -sh 000000080000A578000000E8
11M 000000080000A578000000E8
bash-4.2$ du -sh 000000080000A578000000E8 --apparent-size
16M 000000080000A578000000E8
WAL-диск - это ZFS с активным сжатием, поэтому разница.
Также для завершения, все свойства zfs:
storage/database type filesystem -
storage/database creation Thu Apr 19 12:22 2018 -
storage/database used 1.33T -
storage/database available 369G -
storage/database referenced 1.33T -
storage/database compressratio 2.13x -
storage/database mounted yes -
storage/database quota none default
storage/database reservation none default
storage/database recordsize 16K inherited from storage
storage/database mountpoint /data/
local
storage/database sharenfs off default
storage/database checksum on default
storage/database compression lz4 inherited from storage
storage/database atime off inherited from storage
storage/database devices on default
storage/database exec on default
storage/database setuid on default
storage/database readonly off default
storage/database zoned off default
storage/database snapdir hidden default
storage/database aclinherit restricted default
storage/database createtxg 1159021 -
storage/database canmount on default
storage/database xattr sa inherited from storage
storage/database copies 1 default
storage/database version 5 -
storage/database utf8only off -
storage/database normalization none -
storage/database casesensitivity sensitive -
storage/database vscan off default
storage/database nbmand off default
storage/database sharesmb off default
storage/database refquota none default
storage/database refreservation none default
storage/database guid 8214081110063784152 -
storage/database primarycache all default
storage/database secondarycache all default
storage/database usedbysnapshots 0B -
storage/database usedbydataset 1.33T -
storage/database usedbychildren 0B -
storage/database usedbyrefreservation 0B -
storage/database logbias throughput inherited from storage
storage/database dedup off default
storage/database mlslabel none default
storage/database sync disabled local
storage/database dnodesize legacy default
storage/database refcompressratio 2.13x -
storage/database written 1.33T -
storage/database logicalused 2.82T -
storage/database logicalreferenced 2.82T -
storage/database volmode default default
storage/database filesystem_limit none default
storage/database snapshot_limit none default
storage/database filesystem_count none default
storage/database snapshot_count none default
storage/database snapdev hidden default
storage/database acltype off default
storage/database context none default
storage/database fscontext none default
storage/database defcontext none default
storage/database rootcontext none default
storage/database relatime off default
storage/database redundant_metadata all default
storage/database overlay off default
Но за последние дни ничего не изменилось на диск ZFS - и вся эта проблема только что началась в пятницу (17 июля).
Кроме того, если я скопирую и вставлю команду и запущу ее снова, она мгновенно завершится - все еще работающая команда продолжит зависать.
С помощью ls -lah вы можете следить за тем, как временный файл становится все больше и больше (около 150 КБ / с)
Спасибо всем, кто нашел время, чтобы прочитать это!
Редактировать: Я добавил временную запись в процесс архивирования wal, вот результат:
000000080000A57C00000034 1
000000080000A57C00000035 0
000000080000A57C00000036 0
000000080000A57C00000037 1
000000080000A57C00000038 1
000000080000A57C00000039 119
000000080000A57C0000003A 2
000000080000A57C0000003B 1
000000080000A57C0000003C 127
000000080000A57C0000003D 2
000000080000A57C0000003E 1
000000080000A57C0000003F 1
000000080000A57C00000040 1
000000080000A57C00000041 1
000000080000A57C00000042 1
000000080000A57C00000043 1
000000080000A57C00000044 1
000000080000A57C00000045 1
000000080000A57C00000046 1
000000080000A57C00000047 1
000000080000A57C00000048 1
000000080000A57C00000049 105
000000080000A57C0000004A 2
000000080000A57C0000004B 2
000000080000A57C0000004C 1
000000080000A57C0000004D 1
000000080000A57C0000004E 118
000000080000A57C0000004F 2
000000080000A57C00000050 1
000000080000A57C00000051 120
000000080000A57C00000052 2
000000080000A57C00000053 1
Число справа - это секунды, которые потребовались для выполнения команды Rsync для указанного файла.
Редактировать 2:
Я воссоздал проблему с двумя RAM-накопителями с каждой стороны. Я извлек используемые порты и обнаружил, что все они четные (может быть намек)
Я переключился между подключениями к Интернету на моей стороне (цель), и проблема исчезла. Основываясь на обсуждениях, похоже, что это проблема сети на определенном пути (возможно, из-за балансировки нагрузки)
Я обновлю окончательное решение.
Редактировать 3:
Наш провайдер - Hetzner, у них была ошибка в одном из их модулей DECIX ( https://www.hetzner-status.de/#16045 ). После деактивации проблема исчезла.
Поскольку ошибка была связана с сетью, как первоначально предполагалось, я рекомендую всем выполнить те же действия.
- Повторите одну и ту же передачу за пределами вашего приложения, соберите метрики для времени выполнения, используемых портов, путей маршрутизации.
- Повторите несколько разных интернет-соединений, которые маршрутизируются по-разному
- Обратитесь к своему интернет-провайдеру/провайдеру хостинга с информацией
Оставлять этот вопрос открытым не имеет смысла, так как это периодически возникающая проблема, но, возможно, у кого-то в будущем может быть то же самое.