Собрал я намедни файлопомоечку, поставил систему, сделал raidz2, начал заполнять и удивился тормозам. Копирование на массив по сети со скоростью в районе 400МБ/с вызывало load average 26. Аналогичная картина случилась и в связке mdadm+luks, повторилась на других ядрах и дистрибутивах. Когда похожая ситуация случилась после переноса части массива (диски + HBA) на другое железо, было принято решение менять HBA.

Китайский 9205-8i был заменён на родной (по заверениям продавца) H310, load average спустился на землю, но проблема со скоростью осталась - что zfs raidz2, что mdadm raid6 отказываются работать быстрее 600МБ/с на одном массиве. При этом все винты по отдельности одновременно под аналогичной нагрузкой показывают нормальную скорость. Тесты упростились до dd if=/dev/zero…, если запустить 18 на все диски одновременно - каждый винт выдаст максимально возможную скорость, если собрать raid6 - аналогичное dd выдаст в лучшем случае 600МБ/с, при этом нагрузка равномерно разделится по дискам и ни на одном из них не будет 100% использования. Если собрать 3 массива из 6 дисков в каждом - будет 600х3.

Тестировалось: proxmox 6 с ядрами 5.3.18-3-pve и 5.4.34-1-pve, дебиан 10 с 4.19 и собранным из исходников 5.3.18, какая-то 16 убунта с её родным ядром. Везде ситуация одинаковая. Да, биос последний, mitigations=off, разницы не заметил.

Железо: 2x E5-2620, 96GB DDR3, X9DRI-F, CSE846 с BPN-SAS2-846EL1, H310 (9211-8i), 18 штук WD80EMAZ.

Единственное, что приходит в голову - тормознутые процессоры, но не может же не самый тормозной xeon времён sandy bridge работать медленнее amd a4-3400?

В отдельно взятом офисе наступил долгожданный вендекапец, перевожу на линукс последнее рабочее место - своё. Действующие лица - debian 9, много разных DE, две старые невидии - 9600GT и 8400GS и 4 монитора к ним подключенные.

Проблема - в один момент времени работает только одна пара мониторов. При попытке включить третий, подключенный к другой видяхе - разные варианты отказа разных DE. Cinnamon и enlightment падают при старте, gnome и kde работают на 2 мониторах на одной из видеокарт, xfce работает на всех трёх, но ожидаемо не даёт таскать окна между разными видеокартами и страдает от ШГ, тормозов и адского тиринга.

Проприетарные нвидиедрова не помогли - как не работало, так и не работает.

Живая убунта на этой же машине заработала на всех мониторах сразу, но с тормозами, плюс на одной из видеокарт в движении принципиально не было видно мышь.

Гугл показывает, что ситуация в целом нормальная - иксы таких очевидных вещей не умеют. Отсюда вопрос - как с минимальными потерями времени и ресурсов заставить работать как минимум третий монитор?

Собрал я как-то давно файлопомойку в корпусе Procase ES424, и вот пришло время установить стоечный корпус в стойку. Для этого были куплены procase'овские же рельсы SU-24.

Всё было хорошо до момента установки. Оказалось, что сервер с рельсами на сантиметр толще положенного - 460мм против 450мм - и в стойку не влезает. К такому развитию событий я был отчасти готов, и поэтому сервер был положен на заранее заказанную полку.

Но полка - это неправильно, поэтому вопрос - что делать, и как поставить сервер на рельсы?

Случилось мне на днях позаимствовать 8 терабайт винтов, чего как раз хватило на полный бэкап файлопомойки. Ну и решил я попробовать bcache - потому как тормоза при дампе кэша торрент-клиента изрядно надоели.

Изначально планировалось оставить имеющийся raid6, на него bcache, дальше dm-crypt, затем lvm, и туда уже ФС. Беглые тесты показали, что процессор dm-crypt не тянет (меньше 300мб/с записи, тогда как без него - чуть больше 600мб/с), в результате от шифрования решено было пока отказаться и попробовать собственно bcache.

Для тестов отказался от lvm и накатил ext4 сразу на bcache, скопировал данные, запустил живую нагрузку (5тб торрентов на 365-мбитном канале) и стал ждать. Сперва всё было очень хреново - iowait взлетел с 10-20% до 50+, скорость раздачи упала в 2 раза, тормоза в момент дампа сменились постоянными тормозами - скоростей порядка 3МБ/с я не видел уже очень давно.

Погоревал, да оставил - пусть греется. Грелось оно долго - уже прошли сутки, а из 215 гигов bcache занял всего 187.

А сейчас смотрю и не понимаю нихрена. Кэш уже почти полный, чтение с ssd я вижу, hit ratio - около 40%, что в целом неплохо для такого количества торрентов, вот только iowait упал с 50+ до 20-50 и на ssd нагрузка нет-нет, да бывает 100%. При этом если заполнение кэша отключить (cache_state none), то iowait моментально приходит в норму.

Это ssd такой убогий, или я у bcache не включил что-то очень важное?

Потребовалось мне сделать repair на массиве, который был когда-то собран с --assume-clean, что привело к безумной цифре в mismatch_cnt.

Запустил ребилд, сижу, жду. Всё работает, скорость ребилда около 200МБ/с. Ребилд идёт, скорость потихоньку падает, всё как и положено. Доработало оно примерно до 2/3, и тут скорость упала с ожидаемых ~150МБ/с до 40Мб/с.

iostat показывает примерно такую картину:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00   13.64   40.91    0.00   45.45

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdc           14730.00  4236.00   94.00   62.00 46992.00 15616.00   802.67     7.34   28.28   31.02   24.13   2.31  36.00
sde           14728.00  4219.00   93.00   63.00 46480.00 15616.00   796.10     7.21   26.95   29.42   23.30   2.26  35.20
sdh           14693.00  4268.00   94.00   62.00 45972.00 15616.00   789.59     7.42   27.82   30.68   23.48   2.28  35.60
sdf           14692.00  4220.00   65.00   60.00 31632.00 15104.00   747.78   143.86 1327.74  135.45 2619.40   8.00 100.00
sdd           14692.00  4221.00   92.00   61.00 45968.00 15616.00   805.02     7.31   27.61   30.48   23.28   2.33  35.60
sdg           14690.00  4245.00   93.00   69.00 45968.00 15616.00   760.30     7.63   27.53   30.84   23.07   2.20  35.60
md1               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
md2               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
md3               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
md6               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdi               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    9.64   43.65    0.00   46.70

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    1.00     0.00     0.50     1.00     0.02   16.00    0.00   16.00  16.00   1.60
sdc           11297.00  3969.00   95.00   63.00 45568.00 16128.00   780.96     8.35   52.86   61.14   40.38   2.38  37.60
sde           11297.00  3957.00   95.00   75.00 45568.00 16128.00   725.84     9.85   57.98   72.80   39.20   2.24  38.00
sdh           11296.00  3968.00   96.00   64.00 45568.00 16128.00   771.20    10.71   66.95   81.12   45.69   2.45  39.20
sdf           11296.00  3969.00   96.00   63.00 45568.00 16128.00   776.05     9.63   60.55   73.79   40.38   2.31  36.80
sdd           11299.00  3969.00   79.00   64.00 38280.00 16128.00   760.95   154.94 1191.78  204.46 2410.50   6.99 100.00
sdg           11296.00  3968.00   96.00   64.00 45568.00 16128.00   771.20     9.96   62.27   75.29   42.75   2.30  36.80
md1               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
md2               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
md3               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
md6               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sdi               0.00     0.00    0.00    1.00     0.00     0.50     1.00     0.02   16.00    0.00   16.00  16.00   1.60
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

Да, диск со 100% нагрузкой время от времени меняется, иногда их становится сразу несколько. Данные на массиве в порядке, смарт дисков в порядке, падения производительности в повседневных задачах не ощущается.

У меня одно объяснение - винты из одной партии, в конце дисков много переназначенных на заводе секторов. Я прав, или у этого явления могут быть программные причины?

Участники событий: debian 7, mdadm, sas2008 (LSI 9210-8i в it mode), dt01aca300.

Не могу заставить zabbix 3.0.1 отправлять уведомления.

Сперва пытался поднять jabber - c openfire 3.10.2 и 4.0.1 одна и та же история в ответ на вроде бы корректный логин:

<failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><incorrect-encoding/></failure>

Плюнул, решил написать свой скрипт. Всё хорошо, скрипт вызывается, но без ожидаемых параметров. Что отправлять, кому - непонятно.

When alert script is executed it gets 3 command-line variables (as $1, $2 and $3 respectively)

#!/bin/bash
echo "`date` $1 $2 $3" >> /tmp/zabbix-test

root@zabbix:/tmp# cat /tmp/zabbix-test
Sat Mar  5 00:15:04 MSK 2016
Sat Mar  5 00:21:04 MSK 2016
root@zabbix:/tmp#

Что я делаю не так?

Есть один шлюз на Debian 7.8. Ничего примечательного - держит l2tp до провайдера, openvpn до впски, dnsmasq раздаёт адреса по dhcp и кэширует dns.

С недавних пор у системы начал отваливаться dns. Отваливается следующим образом - в один прекрасный момент любая попытка разрешить имя проваливается. dnsmasq, nslookup, dig - не работает ничего. Сервера, естественно, разные. При этом и запрос и ответ видны в tcpdump, а машины в сети могут спокойно работать напрямую с теми же самыми dns-серверами, которые не работают на шлюзе.

В логах абсолютно ничего необычного. Единственное но - сразу перед падением были кратковременные проблемы с интернетом (это точно было у провайдера - инет отваливался частично). Проблема проявляется далеко не сразу - с последнего ребута (по той же причине) прошло 10 дней.

От напасти не помогает перезапуск впнов, сетевых интерфейсов, и сети вообще. В общем-то, единственное рабочее решение - перезапуск всей машины целиком.

Вопрос - что это может быть, и как это лечится?

Столкнулся с нетривиальной ситуацией.

Провайдер - билайн со своим мерзким l2tp. Сервер на дебиане поднимает соединение и раздаёт интернеты дальше в сеть. Ещё внутри сети есть asterisk на котором настроен сип. Всё настроено и работает.

Однако, если l2tp-соединение падает, а asterisk в этот момент пытается достучаться до сервера, то в conntrack появляется правило с исходящим ip внутренней сети провайдера. И само не исчезает. В результате пакеты сипа после маскарадинга имеют source address вида 10.x.y.z, но уходят в интерфейс ppp0, на котором висит белый ip.

Вопрос - как сделать так, чтобы этой фигни больше не повторилось?

На новой машине при подключении более 16 устройств наблюдается такая картина:

[ 1809.543232] usb 3-7.5.5: new full-speed USB device number 68 using xhci_hcd
[ 1809.561970] usb 3-7.5.5: New USB device found, idVendor=2a0c, idProduct=0001
[ 1809.561977] usb 3-7.5.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1809.561982] usb 3-7.5.5: Product: SCR2
[ 1809.561986] usb 3-7.5.5: Manufacturer: MultiSoft ltd.
[ 1809.562882] usb 3-7.5.5: Not enough host controller resources for new device state.
[ 1809.562901] usb 3-7.5.5: can't set config #1, error -12

Причина гуглится, а вот решение - не очень. Не помогло:

• отключение в биосе всего, что связано с usb3/xhci
• блэклист xhci_hcd
• попытка найти порт, в котором всё работает (lsusb -t показывает корневые хабы на ehci и uhci)

Пока что проблема «решилась» покупкой pci-usb контроллера, но хочется докопаться до истины и всё таки заставить работать родной контроллер.

Железо - мать на B85, линукс - debian 7.8, 3.2.0-4-amd64

Привезли мне тут новую игрушку - пару карточек, да кабель. Собрал, поднял ipoib, протестировал скорость. В одну сторону iperf 11Гбит/с, в другую - 8, что медленнее чем должно было быть, но тоже неплохо. На одном из хостов в процессор упирается.

А с реальными данными всё оказалось намного печальнее. На одной машине raid5 о четырёх винтах, с чтением ~600МБ/с и записью ~500МБ/с. На другой - ненастроенный raid6 на 6 дисках, с чтением ~700МБ/с и записью ~600МБ/с. Копирование в любую сторону - 50МБ/с по ssh и rsync, до 220МБ/с через cifs.

На массивах 4 с лишним терабайта информации, и перегнать её предстоит далеко не один раз.

Куда копать?

И там и там debian 7, opensm-3.3.18.

Здравствуйте, есть ноут с убунтой 14.04LTS и virtualbox. В нём бухгалтерская виртуалка с оффтопиком и банк-клиентами. Ключи на смарт-карте, считыватель CASTLES EZCCID.

На машине с 7 дебианом считыватель видится и пробрасывается нормально. То же самое и на оффтопике. На убунте проброс получается через раз, и гостевая машина считыватель хоть и видит, но работать с ним не может.

После некоторых танцев удалось установить, что считыватель работает если воткнуть его сперва в хаб с питанием, а потом подключить этот хаб к ноуту.

Судя по всему, убунта пытается как-то работать со считывателем и в процессе его подвешивает. Что читать, куда копать?

Есть одна файлопомойка с торрентами и RAID5, который с увеличением количества торрентов и толщины канала начинает заметно тормозить под этой нагрузкой.

Соответственно, хочу оптимизировать доступ к массиву, поставив ему большой SSD под кэш.

Отсюда вопрос - что для этих целей лучше выбрать, и имеет ли смысл этим вообще заниматься? Принимаются любые, самые смелые идеи, готов в том числе поставить другую систему и пересобрать массив. Главное чтобы не падало и требовало поменьше денег.

Цифры для понимания масштаба проблемы:

• Данных (потенциально используемых) - 2.5ТБ
• За месяц добавляется от 100 до 500ГБ.
• Предел чтения в сутки - 2ТБ.
• Реально активно около 15% раздач
• Их общий размер составляет менее 10% от размера данных

Хочется странного - завести второго провайдера как бэкап, а чтобы каналы не простаивали - загрузить всё торрентами.

Поэтому ищется торрент-клиент, который умеет одновременно работать с несколькими интерфейсами. Из требований - вебморда (хотя можно и удалённый клиент, главное чтобы тот под виндой работал), rss, и чтобы умел быть демоном. Бонусом будет просто отлично, если клиент не станет жрать 30мб/с случайного чтения и до 70% времени io на рейд-массиве при раздаче на 10мб/с, как это делает сейчас rtorrent.

Думаю попробовать vuze на предмет запуска без gui и наличия нормального удалённого управления, но может у кого есть опыт подобных утех?