Не уверен на счет правильно ваыбранного раздела, так как грешу больше на железо. Стоит у нас сервер биллинга уже достаточно давно. Настроек никаких не меняли, ipfw практически голый. Сетевухи совсем не нагружены. lavg в среднем 0.20. Основные задачи - utm5_core, utm5_radius, mysqld.

Пару слов о железе:

Два скази харда в зеркале, питаниче через APC, Dual Core AMD Opteron, 4031 MB.

Подробнее о версиях:

utm5-2.1.005
mysql-server-5.0.45_1 (28 запросов/сек, ~77 млн записей)

FreeBSD billing 6.3-STABLE FreeBSD 6.3-STABLE #0: Mon Feb 11 17:32:34 MSK 2008     root@utm.serpuhov.biz:/usr/obj/usr/src/sys/UTM-SMP  i386

=========================================================

Вывод top -S:

last pid: 26179;  load averages:  0.40,  0.28,  0.20                                                                                  up 1+06:23:36  15:28:36
354 processes: 5 running, 331 sleeping, 18 waiting
CPU states:  1.2% user,  0.0% nice,  3.2% system,  0.0% interrupt, 95.6% idle
Mem: 3076M Active, 456M Inact, 238M Wired, 176M Cache, 112M Buf, 5596K Free
Swap: 2048M Total, 612K Used, 2047M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   13 root        1 171   52     0K     8K RUN    0  27.5H 94.53% idle: cpu0
   10 root        1 171   52     0K     8K CPU3   3  28.5H 94.19% idle: cpu3
   11 root        1 171   52     0K     8K CPU2   2  28.4H 92.68% idle: cpu2
   12 root        1 171   52     0K     8K CPU1   1  28.3H 89.06% idle: cpu1
  870 mysql      30  96    0  1627M  1264M ucond  0 174:07  1.42% mysqld
1000 root      222  20  -10  1762M  1745M kserel 0 287:15  0.00% utm5_core
  945 root        8  20    0 10524K  7728K kserel 0   9:38  0.00% utm5_radius
   14 root        1 -32 -151     0K     8K WAIT   0   9:26  0.00% swi4: clock sio
  932 root        6  20    0  4348K  2364K kserel 2   4:00  0.00% utm5_rfw
    4 root        1  -8    0     0K     8K -      2   3:16  0.00% g_down
   32 root        1 -68 -187     0K     8K WAIT   1   2:20  0.00% irq25: bge1
   33 root        1 -64 -183     0K     8K WAIT   2   2:07  0.00% irq28: amr0

=========================================================

systat -v:

    2 users    Load  0.27  0.26  0.19                  Oct 13 15:29

Mem:KB    REAL            VIRTUAL                       VN PAGER   SWAP PAGER
        Tot   Share      Tot    Share    Free           in   out     in   out
Act 3139052   11636  3592312    23712  134564  count
All 3271400   19688  5801512    34332          pages
Proc:                                                            Interrupts
  r   p   d   s   w   Csw  Trp  Sys  Int  Sof  Flt        cow    8286 total
          1 308       40k 4948  36k 1351  301   18        zfod        atkbd0 1
                                                          ozfod     2 bge0 irq24
4.0%Sys   0.1%Intr  5.9%User  0.0%Nice 90.0%Idle        %ozfod    68 bge1 irq25
|    |    |    |    |    |    |    |    |    |    |       daefr   212 amr0 irq28
==>>>                                                     prcfr  2001 cpu0: time
                                        33 dtbuf     1132 totfr  2001 cpu1: time
Namei     Name-cache   Dir-cache    100000 desvn        4 react  2001 cpu3: time
   Calls    hits   %    hits   %     35562 numvn          pdwak  2001 cpu2: time
      40      40 100                 24928 frevn          pdpgs
                                                          intrn
Disks amrd0                                        243632 wire
KB/t  20.64                                       3149660 act
tps     205                                        518464 inact
MB/s   4.13                                        129016 cache
%busy    98                                          5596 free
                                                   114464 buf

=========================================================

my.cnf:

[mysqld]
port            = 3306
socket          = /tmp/mysql.sock
skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
tmp_table_size = 256M
sort_buffer_size = 128M
read_buffer_size = 128M
read_rnd_buffer_size = 16M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 128M
thread_concurrency = 8
skip-networking
server-id       = 1
innodb_data_home_dir = /var/db/mysql/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/db/mysql/
innodb_log_arch_dir = /var/db/mysql/
innodb_buffer_pool_size = 1024M
innodb_additional_mem_pool_size = 40M
innodb_log_file_size = 256M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
innodb_file_per_table=1

=========================================================

kernel conf:

machine         i386
cpu             I486_CPU
cpu             I586_CPU
cpu             I686_CPU
ident           UTM-SMP
options         MAXDSIZ=(2048UL*1024*1024)
options         MAXSSIZ=(728UL*1024*1024)
options         DFLDSIZ=(1024UL*1024*1024)
options         SMP
options         IPFIREWALL
options         IPDIVERT

=========================================================

Вывод на терминал в момент зависания:

kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x3035
fault code = supervisor write, page not presentinstruction pointer = 0x20:0xc867f565
stack pointer = 0x20:8xec860974
frame pointer = 0x20:8xec868974
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32, gran1
processor eflags = resume, IOPL = 0
current process = 878 (mysqld)
trap number = 12
panic: page fault
cpuid = 3

ipfw: install_state: Too many dynamic rules

=========================================================

Что делали:

Включили дамп для создания дебага путем добавления строк в rc.conf:

dumpdev="AUTO"
dumpdir="/var/crash"
savecore_flags="-v"

(ядро и так с "makeoptions     DEBUG=-g"), но после последнего сбоя так ничего и не появилось в /var/crash

Грешили на железо (мол пыль, температура...). Выключили, дали остыть, пропылесосили, но сбой повторился. Виснет обычно либо в выходные, либо ночью после (или в момент) создания резервной копии БД.

По какому пути искать причину сбоя? Еще раз напоминаю, нагрузка существенно не изменялась, конфиги также не менялись. Сервер мог работать месяцами без проблем.