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)

Не мертво то, что в вечности пребудет,
Со смертью времени и смерть умрет.


© Лавкрафт

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)

Оказалось, что немецкий хостер-лоукостер Hetzner в порядке защиты своей инфраструктуры от атак режет, в частности, входящие фрагментированные пакеты UDP, что в современном интернете частично ломает DNS-сервис. Проблема актуальна только тем, кто держит собственные DNS-серверы на физических или виртуальных серверах в Hetzner.

Детально проблема расписана в базе знаний ISC (наш случай - пункт 4. DNS queries/responses using EDNS are allowed, but UDP fragmentation and reassembly is broken), но решение достаточно простое - настроить свой DNS-сервер сообщать другим серверам не посылать требующие фрагментации ответы. Этакий аналог TCP adjust mss, но для DNS через UDP. Более крупные ответы будут доставляться сразу по TCP вместо UDP.

Для сервера BIND достаточно прописать в секции options:

options {
  edns-udp-size 1432;
}

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

Адрес странички всё тот же: https://www.freebsdfoundation.org/donate
dadv: (chuck)
Из экспедиционного дневника Б.Н. Стругацкого - экспедиция АН СССР 1960 г. по поиску места для строительства на Северном Кавказе большого телескопа:

Read more... )
dadv: (tusya)

И рассказанная история, и дискуссия о строгости законов в блоге ныне американской (бывшей советской) иммиграционной адвокатши достойны прочтения.

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 раз, вернувшись к старым значениям.

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