Home » General » Support » Server Crash, seemingly related to VZQUOTA
| Server Crash, seemingly related to VZQUOTA [message #43720] |
Mon, 10 October 2011 01:08  |
bjdea1
Messages: 39
Registered: February 2009
|
Member |
|
|
Hi,
we have a server that seems to be sensitive to vzquotas. I'm not sure if there is a drive issue, or controller issue (Perc 6/i) or whether its the vzquota software but it seems the instability we've been experiencing on our servers could be related to vzquota. When we turn quotas off the server seems more stable. Here are some examples of what we're seeing in our logs:
Oct 10 04:07:25 aunode1 kernel: [ 142.920608] CT: 7018: started
Oct 10 04:07:35 aunode1 kernel: [ 153.316174] VZDQ: detached inode not in creation, orig {2, 5}, dev dm-1, inode 9579670, fs ext4
Oct 10 04:07:35 aunode1 kernel: [ 153.316178] i_count 1,
Oct 10 04:07:35 aunode1 kernel: [ 153.316180] i_mode 100644,
Oct 10 04:07:35 aunode1 kernel: [ 153.316181] i_state 100,
Oct 10 04:07:35 aunode1 kernel: [ 153.316182] i_flags 0
Oct 10 04:07:35 aunode1 kernel: [ 153.316185] i_op ffffffffa025c280, vfs_empty_iops ffffffff823c4780, i_fop ffffffffa025c1a0, i_mapping ffff8803b37edb40
Oct 10 04:07:35 aunode1 kernel: [ 153.316188] current 3016 (flush-253:1), VE 0, time 10.437260
Oct 10 04:07:35 aunode1 kernel: [ 153.316192] Pid: 3016, comm: flush-253:1 Not tainted 2.6.32-042stab039.2 #1
Oct 10 04:07:35 aunode1 kernel: [ 153.316194] Call Trace:
Oct 10 04:07:35 aunode1 kernel: [ 153.316206] [<ffffffffa04fe999>] ? vzquota_inode_qmblk_recalc+0x499/0x4d0 [vzdquota]
Oct 10 04:07:35 aunode1 kernel: [ 153.316220] [<ffffffffa04fece2>] ? vzquota_inode_data+0x82/0x100 [vzdquota]
Oct 10 04:07:35 aunode1 kernel: [ 153.316225] [<ffffffffa0501933>] ? vzquota_claim_reserved_space+0x33/0x180 [vzdquota]
Oct 10 04:07:35 aunode1 kernel: [ 153.316240] [<ffffffffa0228002>] ? ext4_da_update_reserve_space+0x1d2/0x230 [ext4]
Oct 10 04:07:35 aunode1 kernel: [ 153.316252] [<ffffffffa024c3f8>] ? ext4_ext_get_blocks+0x1248/0x19c0 [ext4]
Oct 10 04:07:35 aunode1 kernel: [ 153.316259] [<ffffffff8104f7c3>] ? __wake_up+0x53/0x70
Oct 10 04:07:35 aunode1 kernel: [ 153.316268] [<ffffffffa0229d75>] ? ext4_get_blocks+0xf5/0x2a0 [ext4]
Oct 10 04:07:35 aunode1 kernel: [ 153.316272] [<ffffffff81133c75>] ? pagevec_lookup_tag+0x25/0x40
Oct 10 04:07:35 aunode1 kernel: [ 153.316281] [<ffffffffa022ae8c>] ? mpage_da_map_blocks+0xac/0x450 [ext4]
Oct 10 04:07:35 aunode1 kernel: [ 153.316289] [<ffffffffa01f6a0e>] ? jbd2_journal_stop+0x1fe/0x2e0 [jbd2]
Oct 10 04:07:35 aunode1 kernel: [ 153.316295] [<ffffffffa01f7415>] ? jbd2_journal_start+0xb5/0x100 [jbd2]
Oct 10 04:07:35 aunode1 kernel: [ 153.316303] [<ffffffffa022bac7>] ? ext4_da_writepages+0x2f7/0x660 [ext4]
Oct 10 04:07:35 aunode1 kernel: [ 153.316308] [<ffffffff81132ce1>] ? do_writepages+0x21/0x40
Oct 10 04:07:35 aunode1 kernel: [ 153.316313] [<ffffffff811af09d>] ? __writeback_single_inode+0xdd/0x2c0
Oct 10 04:07:35 aunode1 kernel: [ 153.316316] [<ffffffff811af303>] ? writeback_single_inode+0x83/0xc0
Oct 10 04:07:35 aunode1 kernel: [ 153.316320] [<ffffffff8119ea10>] ? iput+0x30/0x70
Oct 10 04:07:35 aunode1 kernel: [ 153.316323] [<ffffffff811af576>] ? writeback_sb_inodes+0xe6/0x1a0
Oct 10 04:07:35 aunode1 kernel: [ 153.316326] [<ffffffff811af6db>] ? writeback_inodes_wb+0xab/0x1b0
Oct 10 04:07:35 aunode1 kernel: [ 153.316329] [<ffffffff811afa8b>] ? wb_writeback+0x2ab/0x400
Oct 10 04:07:35 aunode1 kernel: [ 153.316334] [<ffffffff814c407a>] ? thread_return+0x4e/0x854
Oct 10 04:07:35 aunode1 kernel: [ 153.316337] [<ffffffff811afd89>] ? wb_do_writeback+0x1a9/0x250
Oct 10 04:07:35 aunode1 kernel: [ 153.316342] [<ffffffff8107c860>] ? process_timeout+0x0/0x10
Oct 10 04:07:35 aunode1 kernel: [ 153.316346] [<ffffffff811afe93>] ? bdi_writeback_task+0x63/0x1b0
Oct 10 04:07:35 aunode1 kernel: [ 153.316350] [<ffffffff81092557>] ? bit_waitqueue+0x17/0xc0
Oct 10 04:07:35 aunode1 kernel: [ 153.316355] [<ffffffff81144950>] ? bdi_start_fn+0x0/0x100
Oct 10 04:07:35 aunode1 kernel: [ 153.316358] [<ffffffff811449d6>] ? bdi_start_fn+0x86/0x100
Oct 10 04:07:35 aunode1 kernel: [ 153.316361] [<ffffffff81144950>] ? bdi_start_fn+0x0/0x100
Oct 10 04:07:35 aunode1 kernel: [ 153.316364] [<ffffffff810920a6>] ? kthread+0x96/0xa0
Oct 10 04:07:35 aunode1 kernel: [ 153.316368] [<ffffffff8100c2ca>] ? child_rip+0xa/0x20
Oct 10 04:07:35 aunode1 kernel: [ 153.316371] [<ffffffff81092010>] ? kthread+0x0/0xa0
Oct 10 04:07:35 aunode1 kernel: [ 153.316374] [<ffffffff8100c2c0>] ? child_rip+0x0/0x20
Oct 10 04:07:44 aunode1 kernel: [ 162.188540] VZDQ: detached inode not in creation, orig {2, 5}, dev dm-1, inode 9579700, fs ext4
Oct 10 04:07:44 aunode1 kernel: [ 162.188544] i_count 1,
Oct 10 04:07:44 aunode1 kernel: [ 162.188546] i_mode 100644,
Oct 10 04:07:44 aunode1 kernel: [ 162.188547] i_state 100,
Oct 10 04:07:44 aunode1 kernel: [ 162.188548] i_flags 0
Oct 10 04:07:44 aunode1 kernel: [ 162.188551] i_op ffffffffa025c280, vfs_empty_iops ffffffff823c4780, i_fop ffffffffa025c1a0, i_mapping ffff8803ad471d00
Oct 10 04:07:44 aunode1 kernel: [ 162.188555] current 3016 (flush-253:1), VE 0, time 19.309626
Oct 10 04:07:44 aunode1 kernel: [ 162.188558] Pid: 3016, comm: flush-253:1 Not tainted 2.6.32-042stab039.2 #1
Oct 10 04:07:44 aunode1 kernel: [ 162.188560] Call Trace:
Oct 10 04:07:44 aunode1 kernel: [ 162.188571] [<ffffffffa04fe999>] ? vzquota_inode_qmblk_recalc+0x499/0x4d0 [vzdquota]
Oct 10 04:07:44 aunode1 kernel: [ 162.188585] [<ffffffffa04fece2>] ? vzquota_inode_data+0x82/0x100 [vzdquota]
Oct 10 04:07:44 aunode1 kernel: [ 162.188589] [<ffffffffa0501933>] ? vzquota_claim_reserved_space+0x33/0x180 [vzdquota]
Oct 10 04:07:44 aunode1 kernel: [ 162.188603] [<ffffffffa0228002>] ? ext4_da_update_reserve_space+0x1d2/0x230 [ext4]
Oct 10 04:07:44 aunode1 kernel: [ 162.188615] [<ffffffffa024c3f8>] ? ext4_ext_get_blocks+0x1248/0x19c0 [ext4]
Oct 10 04:07:44 aunode1 kernel: [ 162.188622] [<ffffffff81239945>] ? submit_bio+0xf5/0x1a0
Oct 10 04:07:44 aunode1 kernel: [ 162.188627] [<ffffffff811bbb5b>] ? bio_alloc_bioset+0x5b/0xf0
Oct 10 04:07:44 aunode1 kernel: [ 162.188636] [<ffffffffa0229d75>] ? ext4_get_blocks+0xf5/0x2a0 [ext4]
Oct 10 04:07:44 aunode1 kernel: [ 162.188640] [<ffffffff81133c75>] ? pagevec_lookup_tag+0x25/0x40
Oct 10 04:07:44 aunode1 kernel: [ 162.188648] [<ffffffffa022ae8c>] ? mpage_da_map_blocks+0xac/0x450 [ext4]
Oct 10 04:07:44 aunode1 kernel: [ 162.188657] [<ffffffffa01f6a0e>] ? jbd2_journal_stop+0x1fe/0x2e0 [jbd2]
Oct 10 04:07:44 aunode1 kernel: [ 162.188663] [<ffffffffa01f7415>] ? jbd2_journal_start+0xb5/0x100 [jbd2]
Oct 10 04:07:44 aunode1 kernel: [ 162.188671] [<ffffffffa022bac7>] ? ext4_da_writepages+0x2f7/0x660 [ext4]
Oct 10 04:07:44 aunode1 kernel: [ 162.188677] [<ffffffff81132ce1>] ? do_writepages+0x21/0x40
Oct 10 04:07:44 aunode1 kernel: [ 162.188681] [<ffffffff811af09d>] ? __writeback_single_inode+0xdd/0x2c0
Oct 10 04:07:44 aunode1 kernel: [ 162.188684] [<ffffffff811af303>] ? writeback_single_inode+0x83/0xc0
Oct 10 04:07:44 aunode1 kernel: [ 162.188688] [<ffffffff8119ea10>] ? iput+0x30/0x70
Oct 10 04:07:44 aunode1 kernel: [ 162.188691] [<ffffffff811af576>] ? writeback_sb_inodes+0xe6/0x1a0
Oct 10 04:07:44 aunode1 kernel: [ 162.188695] [<ffffffff811af6db>] ? writeback_inodes_wb+0xab/0x1b0
Oct 10 04:07:44 aunode1 kernel: [ 162.188698] [<ffffffff811afa8b>] ? wb_writeback+0x2ab/0x400
Oct 10 04:07:44 aunode1 kernel: [ 162.188703] [<ffffffff814c407a>] ? thread_return+0x4e/0x854
Oct 10 04:07:44 aunode1 kernel: [ 162.188706] [<ffffffff811afd89>] ? wb_do_writeback+0x1a9/0x250
Oct 10 04:07:44 aunode1 kernel: [ 162.188711] [<ffffffff8107c860>] ? process_timeout+0x0/0x10
Oct 10 04:07:44 aunode1 kernel: [ 162.188714] [<ffffffff811afe93>] ? bdi_writeback_task+0x63/0x1b0
Oct 10 04:07:44 aunode1 kernel: [ 162.188719] [<ffffffff81092557>] ? bit_waitqueue+0x17/0xc0
Oct 10 04:07:44 aunode1 kernel: [ 162.188723] [<ffffffff81144950>] ? bdi_start_fn+0x0/0x100
Oct 10 04:07:44 aunode1 kernel: [ 162.188726] [<ffffffff811449d6>] ? bdi_start_fn+0x86/0x100
Oct 10 04:07:44 aunode1 kernel: [ 162.188729] [<ffffffff81144950>] ? bdi_start_fn+0x0/0x100
Oct 10 04:07:44 aunode1 kernel: [ 162.188732] [<ffffffff810920a6>] ? kthread+0x96/0xa0
Oct 10 04:07:44 aunode1 kernel: [ 162.188736] [<ffffffff8100c2ca>] ? child_rip+0xa/0x20
Oct 10 04:07:44 aunode1 kernel: [ 162.188739] [<ffffffff81092010>] ? kthread+0x0/0xa0
Oct 10 04:07:44 aunode1 kernel: [ 162.188742] [<ffffffff8100c2c0>] ? child_rip+0x0/0x20
The log goes on and on, many similar such entries repeated.
Anyone seen this before, know of a fix? Thanks
█Deasoft.com Hosting/Software
█AutoBillMe.com Billing Automation
|
|
|
|
| Re: Server Crash, seemingly related to VZQUOTA [message #43721 is a reply to message #43720] |
Mon, 10 October 2011 01:14  |
bjdea1
Messages: 39
Registered: February 2009
|
Member |
|
|
Here's something else I just saw in top output which seems quite strange to me, how can that VE mysqld process be running at 2400% of CPU?????:
[root@aunode1 ~]# top
top - 12:10:47 up 1:24, 2 users, load average: 2.68, 2.37, 2.01
Tasks: 1134 total, 1 running, 1131 sleeping, 0 stopped, 2 zombie
Cpu(s): 19.1%us, 16.7%sy, 0.0%ni, 63.3%id, 0.6%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 16425816k total, 12043776k used, 4382040k free, 1489700k buffers
Swap: 16381944k total, 0k used, 16381944k free, 6111204k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
67622 100 20 0 219m 37m 4232 S 2400.0 0.2 0:06.66 mysqld
92624 root 20 0 237m 20m 9412 S 79.6 0.1 65:41.97 mono
93084 root 20 0 2481m 536m 10m S 20.4 3.3 3:37.48 java
2390 root 20 0 61968 4428 1228 S 3.6 0.0 1:41.58 vmslaved
714929 nobody 20 0 154m 47m 1624 S 1.3 0.3 0:00.05 httpd
716226 root 20 0 15812 2064 932 R 1.3 0.0 0:00.10 top
714533 nobody 20 0 154m 47m 1620 S 1.0 0.3 0:00.03 httpd
715315 nobody 20 0 154m 47m 1620 S 1.0 0.3 0:00.03 httpd
46793 gopher 20 0 190m 134m 3708 S 0.7 0.8 0:10.14 squid3
714928 nobody 20 0 154m 47m 1620 S 0.7 0.3 0:00.03 httpd
715316 nobody 20 0 154m 47m 1620 S 0.7 0.3 0:00.03 httpd
16237 100 20 0 427m 144m 4724 S 0.3 0.9 0:22.70 mysqld
30020 root 20 0 154m 47m 2060 S 0.3 0.3 0:02.17 httpd
36676 root 20 0 85796 7180 2908 S 0.3 0.0 0:04.46 python
37705 root 20 0 58120 1984 520 S 0.3 0.0 0:00.04 sendmail-mta
50676 root 20 0 11572 556 420 S 0.3 0.0 0:09.37 filelockd
715312 nobody 20 0 154m 47m 1620 S 0.3 0.3 0:00.02 httpd
715606 47 20 0 67412 4476 2812 S 0.3 0.0 0:00.01 exim
717359 47 20 0 0 0 0 Z 0.3 0.0 0:00.01 exim <defunct>
1 root 20 0 19332 1504 1212 S 0.0 0.0 0:00.99 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:00.04 migration/0
4 root 20 0 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/0
5 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/0
6 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
7 root RT 0 0 0 0 S 0.0 0.0 0:00.04 migration/1
8 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/1
9 root 20 0 0 0 0 S 0.0 0.0 0:00.04 ksoftirqd/1
10 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/1
11 root RT 0 0 0 0 S 0.0 0.0 0:00.72 migration/2
12 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/2
13 root 20 0 0 0 0 S 0.0 0.0 0:00.03 ksoftirqd/2
14 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/2
15 root RT 0 0 0 0 S 0.0 0.0 0:00.77 migration/3
16 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/3
17 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/3
18 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/3
19 root RT 0 0 0 0 S 0.0 0.0 0:00.03 migration/4
20 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/4
21 root 20 0 0 0 0 S 0.0 0.0 0:00.17 ksoftirqd/4
22 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/4
23 root RT 0 0 0 0 S 0.0 0.0 0:00.05 migration/5
24 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/5
25 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/5
26 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/5
27 root RT 0 0 0 0 S 0.0 0.0 0:00.67 migration/6
28 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/6
29 root 20 0 0 0 0 S 0.0 0.0 0:00.23 ksoftirqd/6
30 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/6
31 root RT 0 0 0 0 S 0.0 0.0 0:00.61 migration/7
32 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/7
█Deasoft.com Hosting/Software
█AutoBillMe.com Billing Automation
[Updated on: Mon, 10 October 2011 01:20] Report message to a moderator |
|
|
|
| Re: Server Crash, seemingly related to VZQUOTA [message #44939 is a reply to message #43721] |
Sat, 14 January 2012 20:30 |
epineda04
Messages: 2
Registered: September 2011
Location: Panama
|
Junior Member |
|
|
Hi all,
This seems to be a common problem.
We are a hosting provide and we had worked with Centos 5 before, and everything used to run smoothly, now that we have a new server with Centos 6, its different.
Despite of having scripts to kill abusers, certain processes as well, and a script to kill processes that use more than 20% of CPU for more than 1 minute, the server keeps on crashing.
Last time i had top running, and the load was 0.78 and all of a sudden the server becomes completely dead, ssh was dead and tty access was dead as well.
Then i started looking at the logs, and the amount of information is simply overwhelming.
Here is the info i can provide to maybe try to come up with a solution to this problem.
Kernel: 2.6.32-042stab039.11
vzctl version 3.0.29.3
Vzquota version 2.5.0
Centos 6 86_64 Bits
Hardware Node: Dual Intel(R) Xeon(R) CPU E5620 @ 2.40GHz Processors
RAM: 48GB
The logs are way to long, but this is kind of what it looks like before it goes completely dead:
Jan 14 13:13:28 S04001011820 kernel: [ 2.499590] usb usb1: Product: EHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 2.499593] usb usb1: Manufacturer: Linux 2.6.32-042stab039.11 ehci_hcd
Jan 14 13:13:28 S04001011820 kernel: [ 2.499597] usb usb1: SerialNumber: 0000:00:1a.7
Jan 14 13:13:28 S04001011820 kernel: [ 2.499645] usb usb1: configuration #1 chosen from 1 choice
Jan 14 13:13:28 S04001011820 kernel: [ 2.499668] hub 1-0:1.0: USB hub found
Jan 14 13:13:28 S04001011820 kernel: [ 2.499672] hub 1-0:1.0: 6 ports detected
Jan 14 13:13:28 S04001011820 kernel: [ 2.499769] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Jan 14 13:13:28 S04001011820 kernel: [ 2.499785] ehci_hcd 0000:00:1d.7: EHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 2.499817] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
Jan 14 13:13:28 S04001011820 kernel: [ 2.499841] ehci_hcd 0000:00:1d.7: debug port 1
Jan 14 13:13:28 S04001011820 kernel: [ 2.503722] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfbed8000
Jan 14 13:13:28 S04001011820 kernel: [ 2.513517] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
Jan 14 13:13:28 S04001011820 kernel: [ 2.513535] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
Jan 14 13:13:28 S04001011820 kernel: [ 2.513539] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Jan 14 13:13:28 S04001011820 kernel: [ 2.513543] usb usb2: Product: EHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 2.513546] usb usb2: Manufacturer: Linux 2.6.32-042stab039.11 ehci_hcd
Jan 14 13:13:28 S04001011820 kernel: [ 2.513549] usb usb2: SerialNumber: 0000:00:1d.7
Jan 14 13:13:28 S04001011820 kernel: [ 2.513602] usb usb2: configuration #1 chosen from 1 choice
Jan 14 13:13:28 S04001011820 kernel: [ 2.513621] hub 2-0:1.0: USB hub found
Jan 14 13:13:28 S04001011820 kernel: [ 2.513625] hub 2-0:1.0: 6 ports detected
Jan 14 13:13:28 S04001011820 kernel: [ 2.513692] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Jan 14 13:13:28 S04001011820 kernel: [ 2.513705] uhci_hcd: USB Universal Host Controller Interface driver
Jan 14 13:13:28 S04001011820 kernel: [ 2.513773] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jan 14 13:13:28 S04001011820 kernel: [ 2.513789] uhci_hcd 0000:00:1a.0: UHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 2.513823] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
Jan 14 13:13:28 S04001011820 kernel: [ 2.513855] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000bc00
Jan 14 13:13:28 S04001011820 kernel: [ 2.513882] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
Jan 14 13:13:28 S04001011820 kernel: [ 2.513884] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Jan 14 13:13:28 S04001011820 kernel: [ 2.513887] usb usb3: Product: UHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 2.513889] usb usb3: Manufacturer: Linux 2.6.32-042stab039.11 uhci_hcd
Jan 14 13:13:28 S04001011820 kernel: [ 2.513891] usb usb3: SerialNumber: 0000:00:1a.0
Jan 14 13:13:28 S04001011820 kernel: [ 2.513924] usb usb3: configuration #1 chosen from 1 choice
Jan 14 13:13:28 S04001011820 kernel: [ 2.513944] hub 3-0:1.0: USB hub found
Jan 14 13:13:28 S04001011820 kernel: [ 2.513948] hub 3-0:1.0: 2 ports detected
Jan 14 13:13:28 S04001011820 kernel: [ 2.514045] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
Jan 14 13:13:28 S04001011820 kernel: [ 2.514061] uhci_hcd 0000:00:1a.1: UHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 2.514089] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
Jan 14 13:13:28 S04001011820 kernel: [ 2.514122] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000b880
Jan 14 13:13:28 S04001011820 kernel: [ 2.514148] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
Jan 14 13:13:28 S04001011820 kernel: [ 2.514150] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Jan 14 13:13:28 S04001011820 kernel: [ 2.514153] usb usb4: Product: UHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 2.514155] usb usb4: Manufacturer: Linux 2.6.32-042stab039.11 uhci_hcd
Jan 14 13:13:28 S04001011820 kernel: [ 2.514157] usb usb4: SerialNumber: 0000:00:1a.1
Jan 14 13:13:28 S04001011820 kernel: [ 2.514191] usb usb4: configuration #1 chosen from 1 choice
Jan 14 13:13:28 S04001011820 kernel: [ 2.514210] hub 4-0:1.0: USB hub found
Jan 14 13:13:28 S04001011820 kernel: [ 2.514214] hub 4-0:1.0: 2 ports detected
Jan 14 13:13:28 S04001011820 kernel: [ 2.514295] uhci_hcd 0000:00:1a.2: PCI INT D -> GSI 19 (level, low) -> IRQ 19
Jan 14 13:13:28 S04001011820 kernel: [ 2.514305] uhci_hcd 0000:00:1a.2: UHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 2.514334] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
Jan 14 13:13:28 S04001011820 kernel: [ 2.514365] uhci_hcd 0000:00:1a.2: irq 19, io base 0x0000b800
Jan 14 13:13:28 S04001011820 kernel: [ 2.514392] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
Jan 14 13:13:28 S04001011820 kernel: [ 2.514395] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Jan 14 13:13:28 S04001011820 kernel: [ 2.514397] usb usb5: Product: UHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 2.514399] usb usb5: Manufacturer: Linux 2.6.32-042stab039.11 uhci_hcd
Jan 14 13:13:28 S04001011820 kernel: [ 2.514401] usb usb5: SerialNumber: 0000:00:1a.2
Jan 14 13:13:28 S04001011820 kernel: [ 2.514435] usb usb5: configuration #1 chosen from 1 choice
Jan 14 13:13:28 S04001011820 kernel: [ 2.514455] hub 5-0:1.0: USB hub found
Jan 14 13:13:28 S04001011820 kernel: [ 2.514458] hub 5-0:1.0: 2 ports detected
Jan 14 13:13:28 S04001011820 kernel: [ 2.514540] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Jan 14 13:13:28 S04001011820 kernel: [ 2.514549] uhci_hcd 0000:00:1d.0: UHCI Host Controller
Jan 14 13:13:28 S04001011820 kernel: [ 3.531204] scsi 0:0:1:0: Direct-Access ATA ST32000542AS CC34 PQ: 0 ANSI: 5
Jan 14 13:13:28 S04001011820 kernel: [ 3.536701] ata2.01: configured for UDMA/133
Jan 14 13:13:28 S04001011820 kernel: [ 3.536942] scsi 1:0:0:0: Direct-Access ATA ST32000542AS CC34 PQ: 0 ANSI: 5
Jan 14 13:13:28 S04001011820 kernel: [ 3.537071] scsi 1:0:1:0: Direct-Access ATA ST31000524AS JC45 PQ: 0 ANSI: 5
Jan 14 13:13:28 S04001011820 kernel: [ 3.584547] sd 1:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
Jan 14 13:13:28 S04001011820 kernel: [ 3.584563] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
Jan 14 13:13:28 S04001011820 kernel: [ 3.584594] sd 0:0:1:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
Jan 14 13:13:28 S04001011820 kernel: [ 3.584600] sd 1:0:0:0: [sdc] Write Protect is off
Jan 14 13:13:28 S04001011820 kernel: [ 3.584621] sd 1:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 14 13:13:28 S04001011820 kernel: [ 3.584687] sd 0:0:0:0: [sda] Write Protect is off
Jan 14 13:13:28 S04001011820 kernel: [ 3.584692] sd 1:0:1:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
Jan 14 13:13:28 S04001011820 kernel: [ 3.584701] sd 0:0:1:0: [sdb] Write Protect is off
Jan 14 13:13:28 S04001011820 kernel: [ 3.584728] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 14 13:13:28 S04001011820 kernel: [ 3.584734] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 14 13:13:28 S04001011820 kernel: [ 3.584845] sd 1:0:1:0: [sdd] Write Protect is off
Jan 14 13:13:28 S04001011820 kernel: [ 3.584885] sd 1:0:1:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 14 13:13:28 S04001011820 kernel: [ 3.584975] sdb:
Jan 14 13:13:28 S04001011820 kernel: [ 3.585067] sda:
Jan 14 13:13:28 S04001011820 kernel: [ 3.585103] sdc: sdb1
Jan 14 13:13:28 S04001011820 kernel: [ 3.591953] sda1 sda2
Jan 14 13:13:28 S04001011820 kernel: [ 3.592688] sd 0:0:0:0: [sda] Attached SCSI disk
Jan 14 13:13:28 S04001011820 kernel: [ 3.592746] sd 0:0:1:0: [sdb] Attached SCSI disk
Jan 14 13:13:28 S04001011820 kernel: [ 3.628574] sdc1
Jan 14 13:13:28 S04001011820 kernel: [ 3.629237] sdd: sdd1
Jan 14 13:13:28 S04001011820 kernel: [ 3.647975] sd 1:0:0:0: [sdc] Attached SCSI disk
Jan 14 13:13:28 S04001011820 kernel: [ 3.648718] sd 1:0:1:0: [sdd] Attached SCSI disk
Jan 14 13:13:28 S04001011820 kernel: [ 3.893018] dracut: Scanning for dmraid devices ddf1_4c5349202020202010000055000000004711471100001450
Jan 14 13:13:28 S0400101182
...
|
|
|
|
| Re: Server Crash, seemingly related to VZQUOTA [message #44941 is a reply to message #43720] |
Sun, 15 January 2012 01:35 |
bjdea1
Messages: 39
Registered: February 2009
|
Member |
|
|
We reverted our server back to Centos 5 and RHEL5 openvz kernel, no problems anymore, however we don't have the new openvz features, like vswap etc.
We do still have one server running RHEL6 Openvz kernel and its been stable for a long time now, no reboots. We have only gradually placed new VPS's on this server and it seems setting up new VPS's goes smoothly with the new OpenVZ kernel. But if you're trying to migrate a current centos 5 VPS's platform to a new centos 6 platform, then its unstable - at least that's been our experience.
So we are placing new clients on this new server - none of our old clients have been placed on this new server and so far its been stable, with about 10 VPS's running. We are using kernel:
2.6.32-042stab037.1
█Deasoft.com Hosting/Software
█AutoBillMe.com Billing Automation
[Updated on: Sun, 15 January 2012 01:37] Report message to a moderator |
|
|
|
| Re: Server Crash, seemingly related to VZQUOTA [message #44944 is a reply to message #44941] |
Sun, 15 January 2012 19:17 |
mustardman
Messages: 91
Registered: October 2009
|
Member |
|
|
Migrating clients over may have something to do with the vzctl problems they are having. Apparently there are still problems with the latest vzctl ( 3.0.30.2) but ymmv.
http://openvz.livejournal.com/39765.html
We had problems migrating over clients from a 32bit RHEL5 node to a 64bit RHEL6 node recently which may have had something to do with the vzctl problem. So we have abandoned that project and are back on RHEL5 for at least another year.
We have noticed those occasional spikes of 1000+% CPU usage etc. on another RHEL6 node we have in production. Seems to happen on 1 or 2 specific processes such as mysqld and yum I think. As far as we can tell it's harmless. Only happens for an instant and doesn't seem to be for real in any way. Maybe a display problem with top?
So far that node has been running smooth for a couple weeks now on the latest RHEL6 kernel. Had a high I/O problem with an earlier kernel but that seems to be fixed now. As the previous poster said, seems to work ok if you are adding new VPS's. Not migrating.
[Updated on: Sun, 15 January 2012 19:23] Report message to a moderator |
|
|
|
| Re: Server Crash, seemingly related to VZQUOTA [message #44945 is a reply to message #44941] |
Sun, 15 January 2012 19:26 |
mustardman
Messages: 91
Registered: October 2009
|
Member |
|
|
bjdea1 wrote on Sat, 14 January 2012 20:35We reverted our server back to Centos 5 and RHEL5 openvz kernel, no problems anymore, however we don't have the new openvz features, like vswap etc.
We do still have one server running RHEL6 Openvz kernel and its been stable for a long time now, no reboots. We have only gradually placed new VPS's on this server and it seems setting up new VPS's goes smoothly with the new OpenVZ kernel. But if you're trying to migrate a current centos 5 VPS's platform to a new centos 6 platform, then its unstable - at least that's been our experience.
So we are placing new clients on this new server - none of our old clients have been placed on this new server and so far its been stable, with about 10 VPS's running. We are using kernel:
2.6.32-042stab037.1
My advice would be to upgrade that kernel. They have fixed a lot of major problems with it since then. We had some I/O problems with that kernel. After about 2 weeks of running smooth the node suddenly had high I/O load. Haven't had that problem since upgrading to the latest kernel.
|
|
|
|
Goto Forum:
Current Time: Tue Aug 13 20:21:30 GMT 2024
Total time taken to generate the page: 0.02867 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
