Не уверен на счет правильно ваыбранного раздела, так как грешу больше на железо. Стоит у нас сервер биллинга уже достаточно давно. Настроек никаких не меняли, 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

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

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

• FreeBSD 6.3-STABLE & kernel trap 12. Начались зависания.,aurved, 22:58 , 13-Окт-09
  • FreeBSD 6.3-STABLE & kernel trap 12. Начались зависания.,kan5300, 01:26 , 14-Окт-09
  • FreeBSD 6.3-STABLE & kernel trap 12. Начались зависания.,aurved, 14:29 , 14-Окт-09
• FreeBSD 6.3-STABLE & kernel trap 12. Начались зависания.,kan5300, 10:36 , 21-Окт-09
• FreeBSD 6.3-STABLE & kernel trap 12. Начались зависания.,kan5300, 14:30 , 01-Дек-09

может это память, стал зависать сервак старый при бекапе базы ночном, memtest сказал типа все окей, а вот утилита стрессового тестирования связки процесссор-память показала дырки в памяти. Тестировал не я, поэтому не помню точно как эта утилитка называется, вроде s&m, но версия была под DOS, ща вроде есть версии этой программки под винду. Завтра спрошу и отпишусь точно про эту утилитку.

Есть еще такое http://dedic.ru/node/66 -- но тут тест длинный, часов 12 гоняется

ок. Я спецом не стал писать наши подозрения, но мы также грешим на хардваре. S&M мне надавно встречался на варезном Live-CD "Alkid". Они еще так забавно предупреждают, что может выйдти из строя аппаратная часть, а когда жмешь "не уверен", появляется сообщение вроде "на самом деле ничего там страшного" или типа того. Вобщем ваще предложение, гонять стресс-тест на связке память-камень? Единственное, еще раз напоминаю, что изза бекапа он вис где-то 3 раза из 7. Бывает просто утром повиснет или днем в выходной.

Спасибо.

>может это память, стал зависать сервак старый при бекапе базы ночном, memtest
>сказал типа все окей, а вот утилита стрессового тестирования связки процесссор-память
>показала дырки в памяти. Тестировал не я, поэтому не помню точно
>как эта утилитка называется, вроде s&m, но версия была под DOS,
>ща вроде есть версии этой программки под винду. Завтра спрошу и
>отпишусь точно про эту утилитку.
>
>Есть еще такое http://dedic.ru/node/66 -- но тут тест длинный, часов 12 гоняется
>

да, это s&m. Eсть версия которая делает загрузочный диск
>

Тесты железа так до сих пор и не провели, ибо сервер в продакшене. Но вот за время моего отсутствия в ветке проявились еще пара странных вещей. Вчера коллега наблюдал странное состояние процесса mysqld в топ. Отправил мускул в перезагрузку и сервер завис с той же ошибкой, что и в сабже. После перезагрузки аномально повысились lavg и база стала тормозить. Вот вывод top на текущий момент:

last pid: 12551;  load averages:  2.05,  1.61,  1.62                                                                                  up 0+15:04:00  10:33:21
247 processes: 5 running, 224 sleeping, 18 waiting
CPU states:  5.2% user,  0.0% nice, 17.6% system,  5.1% interrupt, 72.1% idle
Mem: 1410M Active, 2147M Inact, 201M Wired, 188M Cache, 112M Buf, 5596K Free
Swap: 2048M Total, 400K Used, 2047M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   10 root        1 171   52     0K     8K RUN    3 830:41 96.19% idle: cpu3
   11 root        1 171   52     0K     8K CPU2   2 645:04 71.34% idle: cpu2
   12 root        1 171   52     0K     8K CPU1   1 632:28 66.02% idle: cpu1
   13 root        1 171   52     0K     8K CPU0   0 540:36 52.05% idle: cpu0
   14 root        1 -32 -151     0K     8K WAIT   0 138:01 16.41% swi4: clock sio
1135 root        1  96    0  3596K  2072K select 0   5:30  3.08% ppp
  682 root        1  96    0  4108K  1852K select 2   6:22  2.64% ndsad
1134 root        1  96    0  1408K   832K select 3   3:47  2.15% pptpctrl
  557 root        1 -68    0     0K     8K -      0  44:14  1.42% dummynet
   16 root        1 -44 -163     0K     8K WAIT   1   4:09  1.17% swi1: net
  878 mysql      27  96    0  1627M  1269M ucond  1  68:27  0.88% mysqld
1022 root      116  20  -10   110M    99M kserel 0 573:40  0.00% utm5_core
  940 root        8  20    0  9744K  7112K kserel 0  57:38  0.00% utm5_radius
  942 root        6  20    0  4348K  2496K kserel 0  14:22  0.00% utm5_rfw
   32 root        1 -68 -187     0K     8K WAIT   1   3:37  0.00% irq25: bge1
    4 root        1  -8    0     0K     8K -      1   3:22  0.00% g_down
   33 root        1 -64 -183     0K     8K WAIT   2   3:11  0.00% irq28: amr0

amr0 - это рейд и он все время находится в стостоянии WAIT. Последнее сообщение от биллинга на сервере логов:

Oct 20 19:30:02 billing kernel: SMP: AP CPU #1 Launched!
Oct 20 19:30:02 billing kernel: SMP: AP CPU #2 Launched!
Oct 20 19:30:02 billing kernel: SMP: AP CPU #3 Launched!
Oct 20 19:30:02 billing kernel: Trying to mount root from ufs:/dev/amrd0s1a
Oct 20 19:30:02 billing kernel: WARNING: / was not properly dismounted
Oct 20 19:30:02 billing kernel: WARNING: /home was not properly dismounted
Oct 20 19:30:02 billing kernel: WARNING: /netup was not properly dismounted
Oct 20 19:30:02 billing kernel: WARNING: /usr was not properly dismounted
Oct 20 19:30:02 billing kernel: WARNING: /var was not properly dismounted
Oct 20 19:30:02 billing kernel: /var: mount pending error: blocks 16 files 4

Начал уже грешить на мускул и дисковую подсистему. И всёже мне непонятно почему у меня сайвкор не работает. В конвиге ядра стоит строчка:

makeoptions     DEBUG=-g                # Build kernel with gdb(1) debug symbols

В rc.conf:

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

И после сбоев:

<kan5300@billing>sudo ls /var/crash
minfree

Отвечаю сам себе на случай если кому-то пригодится. Провели тесты всего железа, никаких глюков не нашли. Далее ушли от SMP - увсё стабильно. Далее обновились до RELENG_6 и включили SMP. Полет нормальный.