OpenVZ Forum


Home » International » Russian » Проблема с использованием dcachesize
Проблема с использованием dcachesize [message #16212] Tue, 28 August 2007 11:23 Go to next message
gsaxtc is currently offline  gsaxtc
Messages: 9
Registered: August 2007
Location: Kiev
Junior Member
Почему моя система не хочет их использовать?
Ядро 2.6.18-028stab027 + gentoo

файловая система xfs

cat /proc/user_beancounters| grep "dcachesize|uid" ~
uid resource held maxheld barrier limit failcnt
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 7229638 7446528 0
dcachesize 0 0 9223372036854775807 9223372036854775807 0

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16229 is a reply to message #16212] Wed, 29 August 2007 09:53 Go to previous messageGo to next message
maratrus is currently offline  maratrus
Messages: 1495
Registered: August 2007
Location: Moscow
Senior Member
Гипотеза:
Дело, скорее всего, в том, что пока у вас действительно не идет учет dentry_cache. В пользу этого говорят нули в колонках held и maxheld.
dentry_cache просто пока занимает довольно малый объем памяти.
Для уменьшения накладных расходов, связанных accounting'ом dentry_cache используется следующий принцип. Существуют два пороговых значения. Как только объем памяти, используемой dentry_cache превысит какую-то определенную величину, счетчик включится и будет находится во включенном состоянии, пока размер dentry_cache не станет меньше второй величины.

Размер, занимаемый dentry_cache можно поcмотреть утилитой slabtop.

Значения пороговых значений управляются параметром ядра ubc.dentry_watermark. Утилита sysctl поможет просмотреть значения параметров ядра.
Например, если sysctl -a | grep ubc.dentry_watermark выведет
ubc.dentry_watermark = 0 100
это означает, что счетчик dentry_cache включится, если данный кэш будет занимать 10% памяти и выключится только если кэш опуститься до 0.

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16230 is a reply to message #16229] Wed, 29 August 2007 10:08 Go to previous messageGo to next message
gsaxtc is currently offline  gsaxtc
Messages: 9
Registered: August 2007
Location: Kiev
Junior Member
Загнал
0 0 в

ubc.dentry_watermark = 0 0

ubc.dentry_check = 10
fs.dentry-state = 69660 53089 45 0 0 0

Счетчики побежали,
вот только не совсем ясно,
хорошо это или плохо,
то есть получается кеш работал - но не считался,
а сейчас я наоборот подгрузил машину учетов кеша?


slabtop показывает такое

Active / Total Objects (% used) : 1106660 / 1528000 (72.4%)
Active / Total Slabs (% used) : 79217 / 79227 (100.0%)
Active / Total Caches (% used) : 104 / 161 (64.6%)
Active / Total Size (% used) : 246574.09K / 302587.93K (81.5%)
Minimum / Average / Maximum Object : 0.02K / 0.20K / 128.00K

OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
822991 568713 69% 0.06K 13949 59 55796K page_beancounter
125902 112993 89% 0.56K 17986 7 71944K xfs_inode
125856 112969 89% 0.62K 20976 6 83904K xfs_vnode
104992 93828 89% 0.23K 6562 16 26248K dentry_cache
103908 80286 77% 0.17K 4948 21 19792K vm_area_struct

Вся проблема в том, что машина имея 70% idle - жутко тормозит;(
и имеет высокий LA.

А куда смотреть не ясно, было подозрение - что проблема в диске,
вот и начал искать с dкеша.



top - 13:06:44 up 21:45, 10 users, load average: 13.83, 21.30, 58.76
Tasks: 526 total, 5 running, 516 sleeping, 0 stopped, 0 zombie
Cpu0 : 22.0%us, 7.4%sy, 0.0%ni, 70.3%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu1 : 21.7%us, 7.4%sy, 0.0%ni, 70.3%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st



maratrus wrote on Wed, 29 August 2007 05:53

Гипотеза:
Дело, скорее всего, в том, что пока у вас действительно не идет учет dentry_cache. В пользу этого говорят нули в колонках held и maxheld.
dentry_cache просто пока занимает довольно малый объем памяти.
Для уменьшения накладных расходов, связанных accounting'ом dentry_cache используется следующий принцип. Существуют два пороговых значения. Как только объем памяти, используемой dentry_cache превысит какую-то определенную величину, счетчик включится и будет находится во включенном состоянии, пока размер dentry_cache не станет меньше второй величины.

Размер, занимаемый dentry_cache можно поcмотреть утилитой slabtop.

Значения пороговых значений управляются параметром ядра ubc.dentry_watermark. Утилита sysctl поможет просмотреть значения параметров ядра.
Например, если sysctl -a | grep ubc.dentry_watermark выведет
ubc.dentry_watermark = 0 100
это означает, что счетчик dentry_cache включится, если данный кэш будет занимать 10% памяти и выключится только если кэш опуститься до 0.

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16232 is a reply to message #16230] Wed, 29 August 2007 10:27 Go to previous messageGo to next message
gsaxtc is currently offline  gsaxtc
Messages: 9
Registered: August 2007
Location: Kiev
Junior Member
Очень похоже,
что тормоза начинаются,
когда xfs_inode и dentry_cache доходит до 99-100


вот как тут

819569 559563 68% 0.06K 13891 59 55564K page_beancounter
158578 158543 99% 0.56K 22654 7 90616K xfs_inode
158496 158496 100% 0.62K 26416 6 105664K xfs_vnode
131344 131344 100% 0.23K 8209 16 32836K dentry_cache


Проблема в том,
что нигде не удается найти как влиять на этот параметр.

gsaxtc wrote on Wed, 29 August 2007 06:08

Загнал
0 0 в

ubc.dentry_watermark = 0 0

ubc.dentry_check = 10
fs.dentry-state = 69660 53089 45 0 0 0

Счетчики побежали,
вот только не совсем ясно,
хорошо это или плохо,
то есть получается кеш работал - но не считался,
а сейчас я наоборот подгрузил машину учетов кеша?


slabtop показывает такое

Active / Total Objects (% used) : 1106660 / 1528000 (72.4%)
Active / Total Slabs (% used) : 79217 / 79227 (100.0%)
Active / Total Caches (% used) : 104 / 161 (64.6%)
Active / Total Size (% used) : 246574.09K / 302587.93K (81.5%)
Minimum / Average / Maximum Object : 0.02K / 0.20K / 128.00K

OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
822991 568713 69% 0.06K 13949 59 55796K page_beancounter
125902 112993 89% 0.56K 17986 7 71944K xfs_inode
125856 112969 89% 0.62K 20976 6 83904K xfs_vnode
104992 93828 89% 0.23K 6562 16 26248K dentry_cache
103908 80286 77% 0.17K 4948 21 19792K vm_area_struct

Вся проблема в том, что машина имея 70% idle - жутко тормозит;(
и имеет высокий LA.

А куда смотреть не ясно, было подозрение - что проблема в диске,
вот и начал искать с dкеша.



top - 13:06:44 up 21:45, 10 users, load average: 13.83, 21.30, 58.76
Tasks: 526 total, 5 running, 516 sleeping, 0 stopped, 0 zombie
Cpu0 : 22.0%us, 7.4%sy, 0.0%ni, 70.3%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu1 : 21.7%us, 7.4%sy, 0.0%ni, 70.3%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st



maratrus wrote on Wed, 29 August 2007 05:53

Гипотеза:
Дело, скорее всего, в том, что пока у вас действительно не идет учет dentry_cache. В пользу этого говорят нули в колонках held и maxheld.
dentry_cache просто пока занимает довольно малый объем памяти.
Для уменьшения накладных расходов, связанных accounting'ом dentry_cache используется следующий принцип. Существуют два пороговых значения. Как только объем памяти, используемой dentry_cache превысит какую-то определенную величину, счетчик включится и будет находится во включенном состоянии, пока размер dentry_cache не станет меньше второй величины.

Размер, занимаемый dentry_cache можно поcмотреть утилитой slabtop.

Значения пороговых значений управляются параметром ядра ubc.dentry_watermark. Утилита sysctl поможет просмотреть значения параметров ядра.
Например, если sysctl -a | grep ubc.dentry_watermark выведет
ubc.dentry_watermark = 0 100
это означает, что счетчик dentry_cache включится, если данный кэш будет занимать 10% памяти и выключится только если кэш опуститься до 0.

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16238 is a reply to message #16230] Wed, 29 August 2007 13:57 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member
1. dcachesize при малых объемах не учитывается. Это оптимизация на 2-3%. Дело в том, что dcachesize accounting вообще по большому счету нужен только как защита от DoS одной VE других. Так что при малых объемах dcachesize - считать его и не надо.

2. то что тормозит машина и большой LA это как правило связано либо с самим диском, либо с большой нагрузкой на диск.
сколько у вас LA?
есть ли что-нибудь в dmesg по поводу ошибок или таймаутов на диске?
все ли диски были переведены в DMA режим во время загрузки?
какой у вас disk I/O scheduler используется?

короче либо дайте досутп на ноду посмотреть, либо приаттачьте сюда /var/log/messages, lspci, cat /proc/interrupts && sleep 1 && cat /proc/interrupts, cat /proc/mounts, cat /proc/meminfo

ну может еще чего понадобится потом...

http://static.openvz.org/userbars/openvz-developer.png

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16250 is a reply to message #16238] Wed, 29 August 2007 16:54 Go to previous messageGo to next message
gsaxtc is currently offline  gsaxtc
Messages: 9
Registered: August 2007
Location: Kiev
Junior Member
Ок,
вот что есть

шедулер
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"

cat /proc/mounts

/dev/root / xfs rw,noatime 0 0
proc /proc proc rw,nosuid,nodev,noexec 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,nosuid 0 0
devpts /dev/pts devpts rw,nosuid,noexec 0 0
/dev/sda4 /vservers xfs rw,noatime 0 0
/dev/sdb1 /var/log/apache xfs rw,noatime 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,noexec 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,noexec 0 0
/vservers/private/143 /vservers/root/143 simfs rw 0 0
/dev/root /vservers/root/143/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/143/var/log/apache xfs rw,noatime 0 0
/vservers/private/145 /vservers/root/145 simfs rw 0 0
/dev/root /vservers/root/145/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/145/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/143/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/143/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/146 /vservers/root/146 simfs rw 0 0
/dev/root /vservers/root/146/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/146/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/145/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/145/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/147 /vservers/root/147 simfs rw 0 0
/dev/root /vservers/root/147/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/147/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/146/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/146/dev/pts devpts rw,nosuid,noexec 0 0
proc /vservers/root/147/proc proc rw,nosuid,nodev,noexec 0 0
/vservers/private/149 /vservers/root/149 simfs rw 0 0
/dev/root /vservers/root/149/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/149/var/log/apache xfs rw,noatime 0 0
devpts /vservers/root/147/dev/pts devpts rw,nosuid,noexec 0 0
proc /vservers/root/149/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/149/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/151 /vservers/root/151 simfs rw 0 0
/dev/root /vservers/root/151/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/151/var/log/apache xfs rw,noatime 0 0
/vservers/private/152 /vservers/root/152 simfs rw 0 0
/dev/root /vservers/root/152/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/152/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/151/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/151/dev/pts devpts rw,nosuid,noexec 0 0
proc /vservers/root/152/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/152/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/154 /vservers/root/154 simfs rw 0 0
/dev/root /vservers/root/154/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/154/var/log/apache xfs rw,noatime 0 0
/vservers/private/155 /vservers/root/155 simfs rw 0 0
/dev/root /vservers/root/155/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/155/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/154/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/154/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/156 /vservers/root/156 simfs rw 0 0
/dev/root /vservers/root/156/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/156/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/155/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/155/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/157 /vservers/root/157 simfs rw 0 0
/dev/root /vservers/root/157/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/157/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/156/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/156/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/158 /vservers/root/158 simfs rw 0 0
/dev/root /vservers/root/158/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/158/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/157/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/157/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/159 /vservers/root/159 simfs rw 0 0
/dev/root /vservers/root/159/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/159/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/158/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/158/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/160 /vservers/root/160 simfs rw 0 0
/dev/root /vservers/root/160/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/160/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/159/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/159/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/161 /vservers/root/161 simfs rw 0 0
/dev/root /vservers/root/161/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/161/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/160/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/160/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/164 /vservers/root/164 simfs rw 0 0
/dev/root /vservers/root/164/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/164/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/161/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/161/dev/pts devpts rw,nosuid,noexec 0 0
proc /vservers/root/164/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/164/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/148 /vservers/root/148 simfs rw 0 0
/dev/root /vservers/root/148/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/148/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/148/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/148/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/153 /vservers/root/153 simfs rw 0 0
/dev/root /vservers/root/153/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/153/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/153/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/153/dev/pts devpts rw,nosuid,noexec 0 0
/vservers/private/150 /vservers/root/150 simfs rw 0 0
/dev/root /vservers/root/150/usr/portage xfs rw,noatime 0 0
/dev/sdb1 /vservers/root/150/var/log/apache xfs rw,noatime 0 0
proc /vservers/root/150/proc proc rw,nosuid,nodev,noexec 0 0
devpts /vservers/root/150/dev/pts devpts rw,nosuid,noexec 0 0

cat /proc/meminfo

MemTotal: 4042436 kB
MemFree: 31920 kB
Buffers: 0 kB
Cached: 1025856 kB
SwapCached: 87824 kB
Active: 3406284 kB
Inactive: 226068 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 4042436 kB
LowFree: 31920 kB
SwapTotal: 1952760 kB
SwapFree: 1362016 kB
Dirty: 1584 kB
Writeback: 0 kB
AnonPages: 2577732 kB
Mapped: 170804 kB
Slab: 269800 kB
PageTables: 69264 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 3973976 kB
Committed_AS: 6080388 kB
VmallocTotal: 34359738364 kB
VmallocUsed: 272352 kB
VmallocChunk: 34359465976 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB


cat /proc/interrupts && sleep 1 && cat /proc/interrupts

CPU0 CPU1
0: 21731 10206847 IO-APIC-edge timer
1: 1 24 IO-APIC-edge i8042
8: 0 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
50: 635693 1720653 IO-APIC-level libata
58: 0 0 IO-APIC-level libata
66: 0 22 IO-APIC-level ehci_hcd:usb1
217: 10608180 21 IO-APIC-level eth1
225: 0 61776019 IO-APIC-level ohci_hcd:usb2, eth0
233: 12100769 1424964 IO-APIC-level 3w-xxxx
NMI: 32541 32613
LOC: 10228665 10228648
ERR: 0
MIS: 0
CPU0 CPU1
0: 21731 10206954 IO-APIC-edge timer
1: 1 24 IO-APIC-edge i8042
8: 0 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
50: 635693 1720655 IO-APIC-level libata
58: 0 0 IO-APIC-level libata
66: 0 22 IO-APIC-level ehci_hcd:usb1
217: 10608180 21 IO-APIC-level eth1
225: 0 61776423 IO-APIC-level ohci_hcd:usb2, eth0
233: 12100782 1424964 IO-APIC-level 3w-xxxx
NMI: 32541 32613
LOC: 10228772 10228755
ERR: 0
MIS: 0

cat /var/log/messages

dev wrote on Wed, 29 August 2007 09:57

1. dcachesize при малых объемах не учитывается. Это оптимизация на 2-3%. Дело в том, что dcachesize accounting вообще по большому счету нужен только как защита от DoS одной VE других. Так что при малых объемах dcachesize - считать его и не надо.

2. то что тормозит машина и большой LA это как правило связано либо с самим диском, либо с большой нагрузкой на диск.
сколько у вас LA?
есть ли что-нибудь в dmesg по поводу ошибок или таймаутов на диске?
все ли диски были переведены в DMA режим во время загрузки?
какой у вас disk I/O scheduler используется?

короче либо дайте досутп на ноду посмотреть, либо приаттачьте сюда /var/log/messages, lspci, cat /proc/interrupts && sleep 1 && cat /proc/interrupts, cat /proc/mounts, cat /proc/meminfo

ну может еще чего понадобится потом...
  • Attachment: messages
    (Size: 240.89KB, Downloaded 357 times)

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16262 is a reply to message #16250] Thu, 30 August 2007 08:13 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member
я не знаю заглядывали ли вы в свой /var/log/messages, но там полным полно сообщений от XFS что файловая система corrupted.

http://static.openvz.org/userbars/openvz-developer.png

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16272 is a reply to message #16262] Thu, 30 August 2007 10:37 Go to previous messageGo to next message
gsaxtc is currently offline  gsaxtc
Messages: 9
Registered: August 2007
Location: Kiev
Junior Member
Заглядывал конечно,
я уже просто не могу определить,
что первично.

собственно проблема в том,
что первыми были тормоза,
а потом уже начинает сыпаться xfs

Стоят три аналогичных сервера,
тормоза есть на всех,
а вот xfs посыпалась на том,
где самая большая нагрузка.


Я не знаю с чем связать рассыпание xfs, так как не ясно
что именно первичное.

может xfs не хватает каких-то ресурсов и она начинает рассыпаться?


dev wrote on Thu, 30 August 2007 04:13

я не знаю заглядывали ли вы в свой /var/log/messages, но там полным полно сообщений от XFS что файловая система corrupted.

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16276 is a reply to message #16272] Thu, 30 August 2007 11:31 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member
никакие OVZ ручки не ограничивают XFS в ресурсах, так что это маловероятно. да и нагрузка у вас вряд ли такая, что память днем с огнем на машине не сыщишь...
боюсь что с XFS я помочь не могу совсем Sad кроме как посоветовать смигрировать VE на машинку с ext3.

http://static.openvz.org/userbars/openvz-developer.png

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16277 is a reply to message #16276] Thu, 30 August 2007 11:37 Go to previous messageGo to next message
gsaxtc is currently offline  gsaxtc
Messages: 9
Registered: August 2007
Location: Kiev
Junior Member
проблема в том,
что обычное ядро,
2.6.21xxx
загружается без проблем,
и какаких ошибок xfs - не лезет,
как не давай нагрузки.

Вчера вечером попробовали перевести один из серверов на ext3

закончилось полной смертью системы.

;(

dev wrote on Thu, 30 August 2007 07:31

никакие OVZ ручки не ограничивают XFS в ресурсах, так что это маловероятно. да и нагрузка у вас вряд ли такая, что память днем с огнем на машине не сыщишь...
боюсь что с XFS я помочь не могу совсем Sad кроме как посоветовать смигрировать VE на машинку с ext3.

Report message to a moderator

Re: Проблема с использованием dcachesize [message #16278 is a reply to message #16277] Thu, 30 August 2007 11:42 Go to previous message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member
вы под 2.6.21 гоняли такое же количество приложений как в случае с VE? может в 2.6.21 конечно есть какие-то фиксы к XFS... а можете проверить чистый 2.6.18?

всмысле смертью? вы пытались конвертнуть файловую систему или просто скопировать данные?

http://static.openvz.org/userbars/openvz-developer.png

Report message to a moderator

Previous Topic: VE в качестве OSTEMPLATE
Next Topic: Проблемы с source routing, multihomed, vlan etc.
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Nov 06 16:54:35 GMT 2024

Total time taken to generate the page: 0.04399 seconds
Powered by FUDforum Powered by Virtuozzo Containers