Не уверен на счет правильно ваыбранного раздела, так как грешу больше на железо. Стоит у нас сервер биллинга уже достаточно давно. Настроек никаких не меняли, 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
Грешили на железо (мол пыль, температура...). Выключили, дали остыть, пропылесосили, но сбой повторился. Виснет обычно либо в выходные, либо ночью после (или в момент) создания резервной копии БД.
По какому пути искать причину сбоя? Еще раз напоминаю, нагрузка существенно не изменялась, конфиги также не менялись. Сервер мог работать месяцами без проблем.
