dadv: (chuck)

Отметил свой сороковой день рождения подарком $100 фонду FreeBSD через PayPal. Курс банка 63.29, что немного меньше прошлогоднего. URL прежний: https://www.freebsdfoundation.org/donate/ (биткойны принимают по-прежнему :-)

dadv: (chuck)

Довелось поэкспериментировать с компрессией и шифрованием данных на системном уровне в FreeBSD 9/i386. Шифрование делал через GELI, компрессию через ZFS. Обнаружил забавное. В моём случае контейнер для GELI расположен на медленной сетевой шаре (CIFS over 100Mbit/s & mtu=1500) и для уменьшения дополнительных тормозов от "read-modify-write" поигрался с размерами блоков.

И geli init позволяет задать "размер сектора" в создаваемом GEOM, и ZFS позволяет задать размер блока (recordsize). Оказалось, что даже при отлично сжимаемых данных и включенной компрессии ZFS реально ничего не жмет, если размер сектора и recordsize одинаково равны 4096: zfs get compressratio всегда показывает 1.00 и всё работает довольно медленно, упираясь в сеть.

При том же размере сектора в 4k увеличение recordsize до 8k позволяет ZFS достичь compressratio до 2.0 и операции на хорошо жмущихся данных заметно ускоряются. Если при recordsize=8k уменьшить размер сектора до 512 байт, то на тех же данных степень компрессии взлетает до 16.0 и скорость обработки хорошо жмущихся данных, соответственно, взлетает в разы. Например, показания benchmarks/bonnie, который оперирует как раз такими данными, хорошо демонстрируют эффект.

Маленький "размер сектора" контейнера GELI не слишком хорош по разным причинам: и относительные накладные расходы на собственно шифрование возрастают, и совсем мелкие обмены шифрованными данными по сети через CIFS генерируют относительно высокие накладные расходы в TCP. Поэтому "размер сектора" GELI-контейнера увеличил обратно до размера страницы памяти 4k и выставил ZFS recordsize в 8k - при этом на моих характерных данных коэффициент сжатия получается около 1.85.

Это лишь первая серия тестов и, может быть, в итоге - и для других наборов данных - параметры придется поменять.

dir="/mnt/cifs"
size="100g"
poolopts="-O recordsize=8k -O atime=off -O compression=gzip-9 -o failmode=continue"
truncate -s $size $dir/backend
md=$(mdconfig -af $dir/backend)
geli init -s 4096 /dev/$md
geli attach /dev/$md
zpool create $poolopts es /dev/$md.eli

dadv: (chuck)

Нарастил память у сервера, увеличив с 6G до 6+32=38G. Старый BIOS ругался на неподдерживаемые DIMM, но после обновления заработало всё, кроме одного 32-битного процесса.

Этот сервер работает под управлением FreeBSD 9.3-STABLE/amd64, но внутри себя, кроме всего прочего, крутит jail со спасенной со старой работы системой FreeBSD 4.11, в которой крутится фидонода 2:5006/1 с NNTP-гейтом и innd. И вот нормально работавший при 6G физической памяти innd после расширения стал падать при старте с руганью в лог news.err:

innd: SERVER cant malloc 909626760 bytes at line 146 of chan.c: Cannot allocate memory

Дело в том, что по умолчанию в FreeBSD9/amd64 предел datasize для 32-битных процессов составляет 512M (для 64-битных - 32G), а в innd, очевидно, слишком жадная автонастройка. Поднял системный предел для 32-битных процессов до 2G через sysctl compat.ia32.maxdsiz=2147483648 и проблема ушла.

dadv: (chuck)

Открыл для себя, что named читает ключ rndc.key (нужен, в частности, чтобы работала команда rndc) только из каталога, заданного при компиляции пакета и не имеет опции командной строки для переопределения пути к ключу.

Например, пакет bind910 для FreeBSD 10 нынче собирается с путем конфигурационных файлов /usr/local/etc/namedb и это неудобно, если хочется запускать named в chroot, где иерархия /usr/local вообще не нужна. Средствами /etc/rc.conf можно переопределить путь к named.conf внутри chroot, но нельзя к rndc.conf. Можно это сделать настройками самого named.conf, хотя и неочевидным образом. Перед стандартной секцией options добавляем команды:


include "/etc/namedb/rndc.key";
controls { inet 127.0.0.1 port 953 allow { any; } keys { rndc-key; }; };


Первая команда подключает rndc.key по указанному пути, а вторая команда отменяет поиск его по вкомпилированному пути, включая использование только что подключенного ключа для rndc.

В итоге для того, чтобы установленный из портов/пакетов named в FreeBSD 10 работал в chroot так же, как до этого он работал в составе базовой системы FreeBSD 9 и ранее, в /etc/rc.conf остаётся прописать:

named_enable="YES"
named_conf="/etc/namedb/named.conf"
named_chrootdir="/var/named"
named_symlink_enable="YES"

dadv: (chuck)
В этом году пожертвования можно делать ещё и в биткойнах :-)
Но чего нет, того нет, так что $100 через PayPal ушло традиционно с рублевого счета с конвертацией по банковскому курсу 66.11

Адрес странички всё тот же: https://www.freebsdfoundation.org/donate
dadv: (chuck)

Есть у нас сервер, одна из основных задач которого - получать множество счетчиков по сети, опрашивая разные устройства, сохранять значения счетчиков в файлах RRD и по требованию рисовать графики, всего более 2500 файлов RRD.

На сервере работает два параллельных независимых процесса. Один раз в 5 минут опрашивает множество устройств в сети и за счет высокого параллелизма успевает опросить 2500+ устройств за одну минуту, снимая с каждого устройства одним запросом по нескольку десятков счетчиков и сохраняя эти данные во временных файлах на файловой системе.

Второй стартует тоже раз в 5 минут, но со смещением по времени относительно первого процесса и перемещает данные из временных файлов в базы RRD. До недавнего времени сервер работал под управлением FreeBSD 8.4-STABLE, но в связи с окончанием поддержки (EoS/EoL) восьмой ветки операционная система была обновлена до FreeBSD 9.3-STABLE. До обновления один полный цикл работы этого второго процесса занимал не более минуты, а после обновления он стал работать в 6 раз медленнее. Да и вообще, резкое замедление и уменьшение "отзывчивости" дисковой подсистемы стало заметно невооруженному глазу.

Довольно скоро обнаружил, что всё дело в системном параметре sysctl vfs.read_max, задающем предел для опережающего чтения для UFS в блоках файловой системы. В восьмой версии его значение по умолчанию 8, а в девятой 64. То есть, FreeBSD 8 при чтении одного блока из базы RRD может нагрузить диск чтением восьми блоков, засунув "лишние" данные в кеш, а FreeBSD 9 может нагрузить диск в восемь раз больше плюс занять больше места в кеше. Это может ускорить работу с файлами, когда реально требуется читать файлы целиком или большими кусками.

Но при обновлении RRD-файла выполняется чтение только небольшой части файла и ядерное опережающее чтение впустую нагружает диск и кеш ненужной работой. Уменьшил предел обратно до 8 блоков (старый дефолт) и производительность возрасла в 6 раз, вернувшись к старым значениям.

dadv: (chuck)

В продолжение темы.

Старенький заслуженный Xerox WorkCentre M118 запросил пощады и был заменен новеньким Kyocera FS-6530MFP (ч/б), который понимает PCL XL (PCL 6 Enhanced). В /etc/printcap заменил IP-адрес сетевого принтера на новый и в if-фильтре имя ghostscript-драйвера с ljet4 на pxlmono, после чего команда lpr levels-test.ps сразу напечатала тестовую страницу. На этом вся перенастройка на новый принтер закончилась.

Пользователей навороченных систем печати поздравляю с отмечаемым сегодня всемирным днём счастья.

Profile

dadv: (Default)
Choose your future

June 2017

M T W T F S S
   1234
56 7891011
12131415161718
19202122232425
2627282930  

Syndicate

RSS Atom

Tags

Style Credit

Powered by Dreamwidth Studios