При установке Solaris 11.1 я вижу задержки при получении инкрементного потока zfs. Потоки происходят из установки Solaris 11.0, создаются с использованием zfs send -i и пропущен через mbuffer. В какой-то момент я могу иногда наблюдать снижение производительности записи (практически нет операций чтения или записи на целевых дисках, mpstat отчет об использовании одного и того же или разных ядер, в сумме составляющий чуть более 100% для "системы" с 0 другой нагрузкой):
root@receiver:~# mpstat 5
[...]
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 363 103 213 0 9 4 0 14 0 6 0 94
1 0 0 0 113 3 149 0 11 6 0 16 0 12 0 88
2 1 0 2 40 4 36 0 9 5 0 3 0 1 0 99
3 0 0 0 82 59 18 0 2 3 0 3 0 93 0 7
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 3 0 0 362 104 207 0 9 6 0 12 0 14 0 86
1 0 0 0 90 4 109 0 10 7 0 3 0 17 0 83
2 0 0 0 48 2 40 0 9 3 0 5 0 10 0 90
3 0 0 0 100 54 44 0 7 3 0 4 0 69 0 31
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 332 103 35 0 6 3 0 0 0 45 0 55
1 0 0 0 27 3 22 0 3 1 0 0 0 45 0 55
2 0 0 0 142 3 172 0 9 6 0 4 0 18 0 82
3 0 0 0 181 56 178 0 10 6 0 8 0 1 0 99
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 327 103 54 0 5 2 0 2 0 49 0 51
1 0 0 0 46 3 52 0 9 3 0 0 0 28 0 72
2 0 0 0 156 2 175 0 9 5 0 4 0 25 0 75
3 0 0 0 153 62 132 1 8 6 0 5 0 3 0 97
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 1 380 103 164 0 11 9 0 7 0 5 0 95
1 0 0 0 144 3 165 0 11 9 0 6 0 25 0 75
2 0 0 0 39 1 36 0 6 4 0 2 0 66 0 34
3 0 0 0 125 77 55 0 10 6 0 1 0 14 0 86
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 0 372 107 178 0 9 9 0 19 0 3 0 97
1 0 0 0 145 3 193 0 9 10 0 8 0 8 0 92
2 0 0 0 24 2 26 0 9 3 0 0 0 2 0 98
3 0 0 0 94 86 3 0 0 5 0 0 0 100 0 0
Еще через 200-300 МБ, записанных пакетами, передача практически останавливается:
root@receiver:~# zpool iostat tank 5
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 1.85T 2.01T 511 831 7.76M 4.60M
tank 1.85T 2.01T 0 26 0 65.4K
tank 1.85T 2.01T 3 25 13.2K 62.4K
tank 1.85T 2.01T 4 34 5.00K 76.2K
tank 1.85T 2.01T 3 32 3.10K 87.0K
tank 1.85T 2.01T 0 25 1.20K 59.0K
tank 1.85T 2.01T 6 58 4.30K 339K
tank 1.85T 2.01T 1 28 3.70K 63.1K
tank 1.85T 2.01T 19 30 36.9K 83.2K
И mbuffers на принимающей и отправляющей сторонах загружены на 100%.
Это, кажется, происходит только с более крупными (> 5G) снимками, я действительно вижу задержки в конце потока после того, как первые ГБ были успешно переданы в разумное время. Прием потока все еще работает, просто очень медленно - скорость передачи данных ниже 100 КБ / с (с принимающей стороны mbufferпамять на неработающие диски).
Я также попытался исключить mbuffer из уравнения и передать zfs send поток через SSH прямо в zfs receive, но, похоже, это не имеет большого значения. Снимок в конечном итоге передается, но на последние 1-2 гига уйдут часы.
В противном случае принимающий хост полностью бездействует, в это время сообщения не выводятся на консоль, в журнал сообщений ядра или в / var / log / syslog. Целевой zpool остается пригодным для использования - я все еще могу получить доступ к другим файловым системам, расположенным в том же zpool, в любое время. Кроме того, получение полных, неинкрементных / нерекурсивных потоков zfs размером в сотни ГБ работает без каких-либо проблем со скоростью передачи данных.
Есть ли известная проблема с 11.1 относительно этой проблемы? Как я могу дополнительно диагностировать, чего ждет получатель, когда он должен записать поток?
И zfs send, и zfs receive связаны друг с другом, когда вы соединяете их вместе вот так. Исходная система должна сканировать метаданные zfs в поисках блоков, которые были записаны в инкрементальном интервале, который вы отправляете. Затем вы отправляете это в mbuffer, чтобы поток через сеанс ssh можно было несколько оптимизировать, представив ведро на каждом конце, что может уменьшить задержки и переполнения. Затем канал из mbuffer передает данные в приемник zfs, который должен обрабатывать входящие данные точно так же, как если бы они были записаны. Итак, X транзакций на группу транзакций, сбросить на диск, вычислить метаданные и записать все это вплоть до уберблока. Это может очень походить на застой в потоке и обычно может длиться от 5 до 30 секунд. Если такое падение пропускной способности продолжается более 30 секунд, вероятно, у вас есть ограничения на ресурсы.
В зависимости от того, как настроена ваша система, например, у вас есть быстрый ЗИЛ СЛОГ? Или у вас есть очень большое количество шпинделей позади zpool для оптимизации logbias = пропускной способности? В зависимости от ответов на подобные вопросы вы сможете определить, привязаны ли вы к каким-либо ресурсам или нет.
Ваш CPUS не выглядит слишком разбитым. Я ежедневно вижу серверы с ZPOOL размером более 250 ТБ, которые имеют mpstat intr столбец насчитывает более 20 000. Больше процессоров всегда улучшает показатели mpstat.
Я бы посмотрел на некоторые сценарии dtrace, например zilstat, arcstat, и iopattern среди прочего (проверьте DtraceToolkit), чтобы узнать, что делает система во время ваших пауз.