Fórum Root.cz
Hlavní témata => Server => Téma založeno: pakozdy 14. 06. 2017, 20:21:11
-
zdravim
mam tu jeden starsi server. je fyzicky, 64GB RAM , bezi tam postarsie gentoo 1.12.11 (2.6.27).
ide o tzv konzervu t.j. neaktualizovany, bez konfiguracnych zmien atd. Bezia na nom relativne mala zataz, apache,mysql,2xtomcat (java7).
Jedneho dna oficialne bez nejakych zmien v konfiguracii sa zacala objavovat situacia s OutOfMemory. OOM_killer zacal cistit. Tu prebehla rekonfiguracia oom_killera aby zabil proces ktory ma nedostatok pamate. system tvrdi ze pamate ma dost vid logy nizsie. procesy nevykazuju zvysene cerpanie zdrojov (ps -fe). proste vsetko sa tvari ok, len proste system zacne tuhnut, OOM_KILLER zabija procesy bez nejakej suvislosti - obcas apache, obcas cron, obcas mysql.
netusi niekto co sa moze diat ? v logoch okrem OOM_killer-a nie je nic.
vdaka za akykolvek tip
/proc/meminfo par minut pred killnutim
MemTotal: 65525132 kB
MemFree: 151160 kB
Buffers: 1212 kB
Cached: 62052160 kB
SwapCached: 20 kB
Active: 13988760 kB
Inactive: 50991868 kB
HighTotal: 65137984 kB
HighFree: 142836 kB
LowTotal: 387148 kB
LowFree: 8324 kB
SwapTotal: 16008764 kB
SwapFree: 16008576 kB
Dirty: 76 kB
Writeback: 0 kB
AnonPages: 2926916 kB
Mapped: 10664 kB
Slab: 368824 kB
SReclaimable: 362216 kB
SUnreclaim: 6608 kB
PageTables: 6764 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 65152612 kB
Committed_AS: 3184996 kB
VmallocTotal: 116728 kB
VmallocUsed: 8176 kB
VmallocChunk: 108548 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 6144 kB
DirectMap2M: 911360 kB
vypis z oom_killer
Jun 7 10:50:30 xyz [1382835.254842] Pid: 4386, comm: scheduler_Worke Not tainted 2.6.27-gentoo-r8 #2
Jun 7 10:50:30 xyz [1382835.254846] [<c025c9ea>] oom_kill_process+0x42/0x183
Jun 7 10:50:30 xyz [1382835.254853] [<c025cd4b>] out_of_memory+0x7f/0x188
Jun 7 10:50:30 xyz [1382835.254856] [<c025ee04>] __alloc_pages_internal+0x2ab/0x340
Jun 7 10:50:30 xyz [1382835.254860] [<c025eead>] __get_free_pages+0x14/0x24
Jun 7 10:50:30 xyz [1382835.254863] [<c02af04d>] proc_file_read+0x77/0x1eb
Jun 7 10:50:30 xyz [1382835.254867] [<c02aefd6>] ? proc_file_read+0x0/0x1eb
Jun 7 10:50:30 xyz [1382835.254871] [<c02ab52c>] proc_reg_read+0x56/0x6a
Jun 7 10:50:30 xyz [1382835.254874] [<c02ab4d6>] ? proc_reg_read+0x0/0x6a
Jun 7 10:51:01 xyz [1382835.254877] [<c027ba80>] vfs_read+0x8a/0x131
Jun 7 10:51:01 xyz [1382835.254881] [<c027bdcc>] sys_read+0x3b/0x60
Jun 7 10:51:01 xyz [1382835.254884] [<c02037fd>] sysenter_do_call+0x12/0x21
Jun 7 10:51:01 xyz [1382835.254887] =======================
Jun 7 10:51:01 xyz [1382835.254889] Mem-Info:
Jun 7 10:51:01 xyz [1382835.254890] DMA per-cpu:
Jun 7 10:51:01 xyz [1382835.254892] CPU 0: hi: 0, btch: 1 usd: 0
Jun 7 10:51:01 xyz [1382835.254894] CPU 1: hi: 0, btch: 1 usd: 0
Jun 7 10:51:01 xyz [1382835.254896] CPU 2: hi: 0, btch: 1 usd: 0
Jun 7 10:51:01 xyz [1382835.254897] CPU 3: hi: 0, btch: 1 usd: 0
Jun 7 10:51:01 xyz [1382835.254899] Normal per-cpu:
Jun 7 10:51:01 xyz [1382835.254901] CPU 0: hi: 186, btch: 31 usd: 174
Jun 7 10:51:01 xyz [1382835.254902] CPU 1: hi: 186, btch: 31 usd: 157
Jun 7 10:51:01 xyz [1382835.254904] CPU 2: hi: 186, btch: 31 usd: 140
Jun 7 10:51:01 xyz [1382835.254906] CPU 3: hi: 186, btch: 31 usd: 82
Jun 7 10:51:01 xyz [1382835.254907] HighMem per-cpu:
Jun 7 10:51:01 xyz [1382835.254909] CPU 0: hi: 186, btch: 31 usd: 27
Jun 7 10:51:01 xyz [1382835.254911] CPU 1: hi: 186, btch: 31 usd: 36
Jun 7 10:51:01 xyz [1382835.254913] CPU 2: hi: 186, btch: 31 usd: 40
Jun 7 10:51:01 xyz [1382835.254915] CPU 3: hi: 186, btch: 31 usd: 11
Jun 7 10:51:01 xyz [1382835.254917] Active:4570561 inactive:5244170 dirty:2 writeback:0 unstable:0
Jun 7 10:51:01 xyz [1382835.254918] free:6467781 slab:92722 mapped:2112 pagetables:1769 bounce:0
Jun 7 10:51:01 xyz [1382835.254921] DMA free:3520kB min:64kB low:80kB high:96kB active:48kB inactive:0kB present:15872kB pages_scanned:1548 all_unreclaim
able? yes
Jun 7 10:51:01 xyz [1382835.254923] lowmem_reserve[]: 0 873 63981 63981
Jun 7 10:51:01 xyz [1382835.254928] Normal free:3732kB min:3744kB low:4680kB high:5616kB active:0kB inactive:248kB present:894080kB pages_scanned:6749 al
l_unreclaimable? yes
Jun 7 10:51:01 xyz [1382835.254931] lowmem_reserve[]: 0 0 504866 504866
Jun 7 10:51:01 xyz [1382835.254936] HighMem free:25863872kB min:512kB low:68192kB high:135872kB active:18282196kB inactive:20976432kB present:64622912kB
pages_scanned:0 all_unreclaimable? no
Jun 7 10:51:01 xyz [1382835.254938] lowmem_reserve[]: 0 0 0 0
Jun 7 10:51:01 xyz [1382835.254942] DMA: 90*4kB 145*8kB 9*16kB 4*32kB 1*64kB 3*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 3520kB
Jun 7 10:51:01 xyz [1382835.254952] Normal: 407*4kB 11*8kB 4*16kB 5*32kB 0*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3732kB
Jun 7 10:51:01 xyz [1382835.254961] HighMem: 6*4kB 13*8kB 101768*16kB 386462*32kB 153322*64kB 14891*128kB 334*256kB 2*512kB 2*1024kB 0*2048kB 15*4096kB =
25863872kB
Jun 7 10:51:01 xyz [1382835.254971] 9061133 total pagecache pages
Jun 7 10:51:01 xyz [1382835.254974] 22994 pages in swap cache
Jun 7 10:51:01 xyz [1382835.254976] Swap cache stats: add 169751, delete 146757, find 406968/416882
Jun 7 10:51:01 xyz [1382835.254977] Free swap = 15873612kB
Jun 7 10:51:01 xyz [1382835.254979] Total swap = 16008764kB
Jun 7 10:51:01 xyz [1382835.468059] 16711680 pages RAM
Jun 7 10:51:01 xyz [1382835.468061] 16482304 pages HighMem
Jun 7 10:51:01 xyz [1382835.468062] 330397 pages reserved
Jun 7 10:51:01 xyz [1382835.468063] 4529974 pages shared
Jun 7 10:51:01 xyz [1382835.468064] 5390783 pages non-share
-
zdravim
mam tu jeden starsi server. je fyzicky, 64GB RAM , bezi tam postarsie gentoo 1.12.11 (2.6.27).
ide o tzv konzervu t.j. neaktualizovany, bez konfiguracnych zmien atd. Bezia na nom relativne mala zataz, apache,mysql,2xtomcat (java7).
Jedneho dna oficialne bez nejakych zmien v konfiguracii sa zacala objavovat situacia s OutOfMemory. OOM_killer zacal cistit. Tu prebehla rekonfiguracia oom_killera aby zabil proces ktory ma nedostatok pamate. system tvrdi ze pamate ma dost vid logy nizsie. procesy nevykazuju zvysene cerpanie zdrojov (ps -fe). proste vsetko sa tvari ok, len proste system zacne tuhnut, OOM_KILLER zabija procesy bez nejakej suvislosti - obcas apache, obcas cron, obcas mysql.
netusi niekto co sa moze diat ? v logoch okrem OOM_killer-a nie je nic.
vdaka za akykolvek tip
/proc/meminfo par minut pred killnutim
MemTotal: 65525132 kB
MemFree: 151160 kB
Buffers: 1212 kB
Cached: 62052160 kB
SwapCached: 20 kB
Active: 13988760 kB
Inactive: 50991868 kB
HighTotal: 65137984 kB
HighFree: 142836 kB
LowTotal: 387148 kB
LowFree: 8324 kB
SwapTotal: 16008764 kB
SwapFree: 16008576 kB
Dirty: 76 kB
Writeback: 0 kB
AnonPages: 2926916 kB
Mapped: 10664 kB
Slab: 368824 kB
SReclaimable: 362216 kB
SUnreclaim: 6608 kB
PageTables: 6764 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 65152612 kB
Committed_AS: 3184996 kB
VmallocTotal: 116728 kB
VmallocUsed: 8176 kB
VmallocChunk: 108548 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 6144 kB
DirectMap2M: 911360 kB
vypis z oom_killer
Jun 7 10:50:30 xyz [1382835.254842] Pid: 4386, comm: scheduler_Worke Not tainted 2.6.27-gentoo-r8 #2
Jun 7 10:50:30 xyz [1382835.254846] [<c025c9ea>] oom_kill_process+0x42/0x183
Jun 7 10:50:30 xyz [1382835.254853] [<c025cd4b>] out_of_memory+0x7f/0x188
Jun 7 10:50:30 xyz [1382835.254856] [<c025ee04>] __alloc_pages_internal+0x2ab/0x340
Jun 7 10:50:30 xyz [1382835.254860] [<c025eead>] __get_free_pages+0x14/0x24
Jun 7 10:50:30 xyz [1382835.254863] [<c02af04d>] proc_file_read+0x77/0x1eb
Jun 7 10:50:30 xyz [1382835.254867] [<c02aefd6>] ? proc_file_read+0x0/0x1eb
Jun 7 10:50:30 xyz [1382835.254871] [<c02ab52c>] proc_reg_read+0x56/0x6a
Jun 7 10:50:30 xyz [1382835.254874] [<c02ab4d6>] ? proc_reg_read+0x0/0x6a
Jun 7 10:51:01 xyz [1382835.254877] [<c027ba80>] vfs_read+0x8a/0x131
Jun 7 10:51:01 xyz [1382835.254881] [<c027bdcc>] sys_read+0x3b/0x60
Jun 7 10:51:01 xyz [1382835.254884] [<c02037fd>] sysenter_do_call+0x12/0x21
Jun 7 10:51:01 xyz [1382835.254887] =======================
Jun 7 10:51:01 xyz [1382835.254889] Mem-Info:
Jun 7 10:51:01 xyz [1382835.254890] DMA per-cpu:
Jun 7 10:51:01 xyz [1382835.254892] CPU 0: hi: 0, btch: 1 usd: 0
Jun 7 10:51:01 xyz [1382835.254894] CPU 1: hi: 0, btch: 1 usd: 0
Jun 7 10:51:01 xyz [1382835.254896] CPU 2: hi: 0, btch: 1 usd: 0
Jun 7 10:51:01 xyz [1382835.254897] CPU 3: hi: 0, btch: 1 usd: 0
Jun 7 10:51:01 xyz [1382835.254899] Normal per-cpu:
Jun 7 10:51:01 xyz [1382835.254901] CPU 0: hi: 186, btch: 31 usd: 174
Jun 7 10:51:01 xyz [1382835.254902] CPU 1: hi: 186, btch: 31 usd: 157
Jun 7 10:51:01 xyz [1382835.254904] CPU 2: hi: 186, btch: 31 usd: 140
Jun 7 10:51:01 xyz [1382835.254906] CPU 3: hi: 186, btch: 31 usd: 82
Jun 7 10:51:01 xyz [1382835.254907] HighMem per-cpu:
Jun 7 10:51:01 xyz [1382835.254909] CPU 0: hi: 186, btch: 31 usd: 27
Jun 7 10:51:01 xyz [1382835.254911] CPU 1: hi: 186, btch: 31 usd: 36
Jun 7 10:51:01 xyz [1382835.254913] CPU 2: hi: 186, btch: 31 usd: 40
Jun 7 10:51:01 xyz [1382835.254915] CPU 3: hi: 186, btch: 31 usd: 11
Jun 7 10:51:01 xyz [1382835.254917] Active:4570561 inactive:5244170 dirty:2 writeback:0 unstable:0
Jun 7 10:51:01 xyz [1382835.254918] free:6467781 slab:92722 mapped:2112 pagetables:1769 bounce:0
Jun 7 10:51:01 xyz [1382835.254921] DMA free:3520kB min:64kB low:80kB high:96kB active:48kB inactive:0kB present:15872kB pages_scanned:1548 all_unreclaim
able? yes
Jun 7 10:51:01 xyz [1382835.254923] lowmem_reserve[]: 0 873 63981 63981
Jun 7 10:51:01 xyz [1382835.254928] Normal free:3732kB min:3744kB low:4680kB high:5616kB active:0kB inactive:248kB present:894080kB pages_scanned:6749 al
l_unreclaimable? yes
Jun 7 10:51:01 xyz [1382835.254931] lowmem_reserve[]: 0 0 504866 504866
Jun 7 10:51:01 xyz [1382835.254936] HighMem free:25863872kB min:512kB low:68192kB high:135872kB active:18282196kB inactive:20976432kB present:64622912kB
pages_scanned:0 all_unreclaimable? no
Jun 7 10:51:01 xyz [1382835.254938] lowmem_reserve[]: 0 0 0 0
Jun 7 10:51:01 xyz [1382835.254942] DMA: 90*4kB 145*8kB 9*16kB 4*32kB 1*64kB 3*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 3520kB
Jun 7 10:51:01 xyz [1382835.254952] Normal: 407*4kB 11*8kB 4*16kB 5*32kB 0*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3732kB
Jun 7 10:51:01 xyz [1382835.254961] HighMem: 6*4kB 13*8kB 101768*16kB 386462*32kB 153322*64kB 14891*128kB 334*256kB 2*512kB 2*1024kB 0*2048kB 15*4096kB =
25863872kB
Jun 7 10:51:01 xyz [1382835.254971] 9061133 total pagecache pages
Jun 7 10:51:01 xyz [1382835.254974] 22994 pages in swap cache
Jun 7 10:51:01 xyz [1382835.254976] Swap cache stats: add 169751, delete 146757, find 406968/416882
Jun 7 10:51:01 xyz [1382835.254977] Free swap = 15873612kB
Jun 7 10:51:01 xyz [1382835.254979] Total swap = 16008764kB
Jun 7 10:51:01 xyz [1382835.468059] 16711680 pages RAM
Jun 7 10:51:01 xyz [1382835.468061] 16482304 pages HighMem
Jun 7 10:51:01 xyz [1382835.468062] 330397 pages reserved
Jun 7 10:51:01 xyz [1382835.468063] 4529974 pages shared
Jun 7 10:51:01 xyz [1382835.468064] 5390783 pages non-share
Co vypise ulimit -a
?
V jave muzes dostat OOM i z duvodu nedostatku resources - napr. file descriptoru. Zkus navisit pocet FD na proces.
-
Java neumre na OOM. to by som nasiel v java logoch. tam je ticho, ale oom_killer zabije java proces. predpokladam ze
keby jave dosla pamat, osetri si to sama. Navyse v killovanych procesoch sa java casto nevyskutuje.
java ma nastavenu dynamicku pamat 700-2048, 500-2048 . Ale cakal by som ze v logoch ostane od systemu aspon nejaky smrad ze dochadza k pretlaku.
este ma napadlo ze tam bezia 32b verzie programov, kernel vyzera byt 32bit(i686) bez PAE.
ulimit vyzera ok.
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 522240
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 522240
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
-
mam tu jeden starsi server. je fyzicky, 64GB RAM
kernel vyzera byt 32bit(i686) bez PAE.
Pobavils... ;D ::) :o
-
Kernel je buď 64-bit nebo 32-bit z PAE, jinak by nemohl využít těch 64GB, což by pak dávalo jiné čísla v /proc/meminfo
V obou případěch bych zkusil upgrade, pokud to s danou distribucí nějak půjde, správa paměti se postupně zlepšovala. Zvláště v případě, že je tam PAE, které je samo o sobě velká magie se spoustou omezení.
Příčina, proč teď najednou a ne dřív, může být spousta - větší load, větší traffic a rychlejší potřeba alokace paměti, na kterou kernel nestíhá správně reagovat (pomalost uvolňování / zapisování cache / buffers, či jednoduše nějaká chyba - race condition, whatever). 2.6.27 je hodně stará verze, takže upgrade může snadno vyřešit...
-
Pokud tam máte PAE, systém dokáže využít těch 64 GB RAM a přidělit je různým procesům. Ale každý proces stejně dokáže naadresovat — všimněte si, nepíšu naalokovat — pouze 3 GB viruálního adresního prostoru. Proces tak může mít naalokováno třeba jen 300 MB fyzické paměti, ale může havarovat na nedostatek virtuální paměti (přes 3 GB). Virtuální paměť mohou potřebovat různé sdílené paměťové segmenty, vlákna, soubory namapované do paměti a podobně. Specialistou na spotřebu virtuálního adresního prostoru je například baloo z KDE (270 GB, předpokládám namapované soubory).
Přehled o alokaci můžete zjistit pomocí ps: ps -xa -o vsz,pid,comm | sort -n
Podrobný výpis alokací paměťového prostoru lze zjistit pomocí programu pmap.
-
Pridejte vypis sysctl.conf
-
/etc/sysctl.conf
#
# For more information on how this file works, please see
# the manpages sysctl(8) and sysctl.conf(5).
#
# In order for this file to work properly, you must first
# enable 'Sysctl support' in the kernel.
#
# Look in /proc/sys/ for all the things you can setup.
#
# Disables packet forwarding
#net.ipv4.ip_forward = 0
# Disables IP dynaddr
#net.ipv4.ip_dynaddr = 0
# Disable ECN
#net.ipv4.tcp_ecn = 0
# Enables source route verification
net.ipv4.conf.default.rp_filter = 1
# Enable reverse path
net.ipv4.conf.all.rp_filter = 1
# Enable SYN cookies (yum!)
# http://cr.yp.to/syncookies.html
#net.ipv4.tcp_syncookies = 1
# Disable source route
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv4.conf.default.accept_source_route = 0
# Disable redirects
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv4.conf.default.accept_redirects = 0
# Disable secure redirects
#net.ipv4.conf.all.secure_redirects = 0
#net.ipv4.conf.default.secure_redirects = 0
# Ignore ICMP broadcasts
#net.ipv4.icmp_echo_ignore_broadcasts = 1
# Disables the magic-sysrq key
#kernel.sysrq = 0
# When the kernel panics, automatically reboot in 3 seconds
#kernel.panic = 3
# Allow for more PIDs (cool factor!); may break some programs
#kernel.pid_max = 999999
# You should compile nfsd into the kernel or add it
# to modules.autoload for this to work properly
# TCP Port for lock manager
#fs.nfs.nlm_tcpport = 0
# UDP Port for lock manager
#fs.nfs.nlm_udpport = 0
#
# oom_kill zmeny
vm.overcommit_memory = 2
vm.overcommit_ratio = 75
vm.oom_kill_allocating_task=1
vm.oom_dump_tasks=1
a sysctl -a bez sietovych veci
kernel.sched_rt_period_us = 1000000
kernel.sched_rt_runtime_us = 950000
kernel.sched_compat_yield = 0
kernel.panic = 0
kernel.core_uses_pid = 0
kernel.core_pattern = core
kernel.tainted = 0
kernel.real-root-dev = 0
kernel.print-fatal-signals = 0
kernel.ctrl-alt-del = 0
kernel.modprobe = /sbin/modprobe
kernel.hotplug =
kernel.sg-big-buff = 32768
kernel.acct = 4 2 30
kernel.sysrq = 1
kernel.cad_pid = 1
kernel.threads-max = 1044480
kernel.random.poolsize = 4096
kernel.random.entropy_avail = 2410
kernel.random.read_wakeup_threshold = 64
kernel.random.write_wakeup_threshold = 128
kernel.random.boot_id = 66ef57ea-ecf5-423f-886f-660640108a5f
kernel.random.uuid = ebdcbac3-e95e-4382-ae9c-4bdf14a26855
kernel.overflowuid = 65534
kernel.overflowgid = 65534
kernel.pid_max = 32768
kernel.panic_on_oops = 0
kernel.printk = 1 4 1 7
kernel.printk_ratelimit = 5
kernel.printk_ratelimit_burst = 10
kernel.ngroups_max = 65536
kernel.unknown_nmi_panic = 0
kernel.nmi_watchdog = 0
kernel.panic_on_unrecovered_nmi = 0
kernel.bootloader_type = 113
kernel.kstack_depth_to_print = 24
kernel.io_delay_type = 0
kernel.randomize_va_space = 2
kernel.acpi_video_flags = 0
kernel.max_lock_depth = 1024
kernel.maps_protect = 0
kernel.poweroff_cmd = /sbin/poweroff
kernel.keys.maxkeys = 200
kernel.keys.maxbytes = 20000
kernel.keys.root_maxkeys = 200
kernel.keys.root_maxbytes = 20000
kernel.ostype = Linux
kernel.osrelease = 2.6.27-gentoo-r8
kernel.version = #2 SMP Wed Apr 8 14:56:45 CEST 2009
kernel.hostname = ovbbox
kernel.domainname = (none)
kernel.shmmax = 33554432
kernel.shmall = 2097152
kernel.shmmni = 4096
kernel.msgmax = 8192
kernel.msgmni = 755
kernel.msgmnb = 16384
kernel.sem = 250 32000 32 128
kernel.auto_msgmni = 1
kernel.pty.max = 4096
kernel.pty.nr = 2
vm.overcommit_memory = 2
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 1
vm.oom_dump_tasks = 1
vm.overcommit_ratio = 75
vm.page-cluster = 3
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.dirty_writeback_centisecs = 499
vm.dirty_expire_centisecs = 2999
vm.nr_pdflush_threads = 2
vm.swappiness = 60
vm.nr_hugepages = 0
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0
vm.lowmem_reserve_ratio = 256 32 32
vm.drop_caches = 0
vm.min_free_kbytes = 3815
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65536
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.stat_interval = 1
vm.mmap_min_addr = 65536
vm.vdso_enabled = 1
vm.highmem_is_dirtyable = 0
fs.inode-nr = 10920 309
fs.inode-state = 10920 309 0 0 0 0 0
fs.file-nr = 1264 0 6486236
fs.file-max = 6486236
fs.nr_open = 1048576
fs.dentry-state = 11235 9468 45 0 0 0
fs.overflowuid = 65534
fs.overflowgid = 65534
fs.leases-enable = 1
fs.dir-notify-enable = 1
fs.lease-break-time = 45
fs.aio-nr = 0
fs.aio-max-nr = 65536
fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 8192
fs.inotify.max_queued_events = 16384
fs.epoll.max_user_instances = 128
fs.epoll.max_user_watches = 119020
fs.suid_dumpable = 0
fs.binfmt_misc.status = enabledfs.quota.lookups = 0
fs.quota.drops = 0
fs.quota.reads = 0
fs.quota.writes = 0
fs.quota.cache_hits = 0
fs.quota.allocated_dquots = 0
fs.quota.free_dquots = 0
fs.quota.syncs = 12
fs.nfs.nfs_callback_tcpport = 0
fs.nfs.idmap_cache_timeout = 600
fs.nfs.nfs_mountpoint_timeout = 500
fs.nfs.nfs_congestion_kb = 259008
fs.nfs.nlm_grace_period = 0
fs.nfs.nlm_timeout = 10
fs.nfs.nlm_udpport = 0
fs.nfs.nlm_tcpport = 0
fs.nfs.nsm_use_hostnames = 0
fs.nfs.nsm_local_state = 0
fs.mqueue.queues_max = 256
fs.mqueue.msg_max = 10
fs.mqueue.msgsize_max = 8192
debug.exception-trace = 1
dev.scsi.logging_level = 0
dev.raid.speed_limit_min = 1000
dev.raid.speed_limit_max = 200000
dev.hpet.max-user-freq = 64
dev.mac_hid.mouse_button_emulation = 0
dev.mac_hid.mouse_button2_keycode = 97
dev.mac_hid.mouse_button3_keycode = 100
sunrpc.rpc_debug = 0
sunrpc.nfs_debug = 0
sunrpc.nfsd_debug = 0
sunrpc.nlm_debug = 0
sunrpc.transports = tcp 1048576
sunrpc.transports = udp 32768
sunrpc.udp_slot_table_entries = 16
sunrpc.tcp_slot_table_entries = 16
sunrpc.min_resvport = 665
sunrpc.max_resvport = 1023
-
Java neumre na OOM. to by som nasiel v java logoch. tam je ticho, ale oom_killer zabije java proces. predpokladam ze
keby jave dosla pamat, osetri si to sama. Navyse v killovanych procesoch sa java casto nevyskutuje.
java ma nastavenu dynamicku pamat 700-2048, 500-2048 . Ale cakal by som ze v logoch ostane od systemu aspon nejaky smrad ze dochadza k pretlaku.
este ma napadlo ze tam bezia 32b verzie programov, kernel vyzera byt 32bit(i686) bez PAE.
ulimit vyzera ok.
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 522240
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 522240
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
no me se moc nelibi tento radek
open files (-n) 1024
dejte to aspon na 8192
-
Blba otazka, je dost mista na disku? 8)
-
este ma napadlo ze tam bezia 32b verzie programov, kernel vyzera byt 32bit(i686) bez PAE.
no jako prvni bych zkusil kompilovat stejny kernel se stejnou konfiguraci, ale 64b, userspace se vubec menit nemusi, ale sprava pameti bude daleko lepsi
teda pokud nekde budes mit gcc 64bit, ktere ten archaicky kernel prelozi
pripadne zkusit "nejnovejsi" 2.6.27.x x=57 nebo 2.6.39.4? treba ty novejsi kernely soucasne gcc zvladne
-
zdá se, že 2.6.27.57 i 2.6.39.4 by mělo jet s gcc4, gcc5 nejde, ted jsem zkousel
-
Ale každý proces stejně dokáže naadresovat — všimněte si, nepíšu naalokovat — pouze 3 GB viruálního adresního prostoru. Proces tak může mít naalokováno třeba jen 300 MB fyzické paměti, ale může havarovat na nedostatek virtuální paměti (přes 3 GB).
To ale přece nevyvolá OOM killer (který se navíc nevyvolává při alokacích, ale až když začneš namapované stránky špinit), ale malloc/sbrk mu prostě vrátí -1, ne?
Pro tazatele: můžeš vypnout memory overcommit? Teoreticky by se pak v logu mohl ukázat proces, který to _opravdu_ způsobil.
-
malloc
mmap, samozřejmě. Sorry.
-
vymena jadra je trocha problem - je to proste konzerva do ktorej nikto nechce velmi sparat. navyse gentoo vidim prvy raz a s kernelmi som na tejto distribucii nerobil takze je tam vysoke riziko uplneho polamania.
skusim detailnejsie zistit cerapania pamate.
na uvod zmenim nastavenia javy a mysql aby to zozralo max 2,5GB.
-
overcommit je vypnuty vid: sysctl.conf vm.overcommit_memory = 2
oom_killer vypise problemovy proces, ale vzdy ide o rozne mysql, apache, bash skript cron.
Ale každý proces stejně dokáže naadresovat — všimněte si, nepíšu naalokovat — pouze 3 GB viruálního adresního prostoru. Proces tak může mít naalokováno třeba jen 300 MB fyzické paměti, ale může havarovat na nedostatek virtuální paměti (přes 3 GB).
To ale přece nevyvolá OOM killer (který se navíc nevyvolává při alokacích, ale až když začneš namapované stránky špinit), ale malloc/sbrk mu prostě vrátí -1, ne?
Pro tazatele: můžeš vypnout memory overcommit? Teoreticky by se pak v logu mohl ukázat proces, který to _opravdu_ způsobil.
-
vymena jadra je trocha problem - je to proste konzerva do ktorej nikto nechce velmi sparat. navyse gentoo vidim prvy raz a s kernelmi som na tejto distribucii nerobil takze je tam vysoke riziko uplneho polamania.
na gentoo si kazdy jadro kompiluje sam :) anebo genkernel, ale to je jen pro baby ;D
tak nekam dej .config a ja vyrobim 2.6.39, ten se mi tu zkompiluje gcc4.9.4 jen s jednou opravou, 2.6.27 tam tech problemu ma vic
-
dik za ponuku, ale musim pockat na vyjadrenie k zmene kernel-u, nezalezi to iba na mne.
v podstate by chceli aby to chodilo ale aby sa tam nic nezmenilo :-)
-
v podstate by chceli aby to chodilo ale aby sa tam nic nezmenilo :-)
haha, no jo managori
vsak to muzete vyzkouset na necisto na jinym stroji, naklonujes, vsechno stejny, jen jadro 64b a kdyz to prestane delat, tak to pochopi i managori , snad teda ;D
-
jestli by teda chteli, aby se nic nemenilo, tak bych doporucil cron job, ktery kontroluje, co bylo zabito a pousti to znova ;)
-
Ja by som problem videl prave v tom, ze je vypnuty overcommit_memory, pretoze default overcommit_ratio=50 (t.j 50% (RAM + SWAP)) pri zapnutom heuristickom overcommite (overcommit_memory=0)
Ak je overcommit_memory vypnuty (tj. nastaveny na 2), overcommit_ratio by malo byt nastavene na hodnotu 100 (100% (RAM + SWAP))
echo 100 > /proc/sys/vm/overcommit_ratio
ak to nepomoze, skus nastavit defaultne hodnoty pre overcommit_memory a overcommit_ratio
echo 0 > /proc/sys/vm/overcommit_memory
echo 50 > /proc/sys/vm/overcommit_ratio
Este pozri ake je vytazenie swapu, podla vypisu z meminfo mas 64GB RAM a 16GB SWAP.
Ak sa ti spusta nejaky cron proces ktory cita vela suborov, je mozne ze defaultna hodnota swappiness=60 moze sposobovat problemy. (t.j. extremne sa zvacsi suborova cache, a aktivne procesy mozu byt odswapovane a potom nasledne zostrelene OOM)
Skus nastavit swappiness na nizsiu hodnotu (default je 60% RAM)
echo 10 > /proc/sys/vm/swappiness
Update kernelu by som videl ako poslednu moznost, a rozhodne by som najskor naklonoval system do virtualky a tam sa s tym pohral, a poriadne otestoval kombinaciu novy KERNEL + stare GCC & stare GLIBC.
-
Az teraz som si vsimol, ze ste postli vas sysctl.conf
vase hodnoty:
# oom_kill zmeny
vm.overcommit_memory = 2
vm.overcommit_ratio = 75
Pri vypnutom memory_overcommit, by malo byt overcommit_ratio nastavene na hodnotu 100 (100% (RAM + SWAP):
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
-
Pri vypnutom memory_overcommit, by malo byt overcommit_ratio nastavene na hodnotu 100 (100% (RAM + SWAP):
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
Z dokumentace jsem nabyl dojmu, že to znamená (100% RAM) + SWAP.
Anyway, i když má blbě overcommit_ratio, tak při overcommit_memory = 2 by se OOM killer neměl vyvolávat vůbec nikdy, ne? Nebo chápu fungování overcommitu úplně blbě?
-
teoreticky by to melo OOM vypnout, ale prakticky se toto nastaveni na produkcnim serveru nedoporucuje:
http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html (http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html)
bych zkusil mozna overcomit vypnout a podle toho navodu zde ochranit pred oom proces, ktery chci aby nebyl zabit
stejne to dlouhodobe vidim na nutnost toho 64b kernelu
-
pane Linusi... můžeš prosím poslat výstup
uname -a a
cat /proc/cpuinfo(u cpuinfo stačí jedno jádro)
ať se tu případně neřeší blbosti?
-
stejne to dlouhodobe vidim na nutnost toho 64b kernelu
Prošel jsem celou diskuzi a nevšiml jsem si, že by tazatel dodal informaci o tom, jestli má 64 bit kernel nebo 32 bit s PAE. Pokud je to druhá možnost, platí co bylo napsáno výše o omezení virtuálního paměťového jednotlivých aplikací a 64 bit kernel to nezachrání, protože má podobné omezení pro 32 bit aplikace. I když to může pomoct a problém (na čas) vyřešit, protože u 32 bit kernelu má 32 bit binárka omezení na 3 GB, zatímco s 64 bit kernelem má omezení na 4 GB. Aby mohly aplikace využívat více, musejí být také 64 bit.
-
No, vidím, že stále "řešíme"... Prosímtě, pokud chceš skutečně něco řešit a ne "řešit", tak si nainstaluj normální aktuální stroj s amd64 architekturou, tam začni testovat a až to bude otestované a ready, tak to přepni "konzervu" zlikviduj.
Jako provozovat x86 instalaci s 32bitovým jádrem 2.6.x na stroji s 64GB RAM je prostě hyperkokotina, sorry jako. O strategii "konzerva" ani nemluvě, co to je proboha za nápad nic neaktulizovat? To ty hromady děr nevadí?
-
stejne to dlouhodobe vidim na nutnost toho 64b kernelu
Prošel jsem celou diskuzi a nevšiml jsem si, že by tazatel dodal informaci o tom, jestli má 64 bit kernel nebo 32 bit s PAE. Pokud je to druhá možnost, platí co bylo napsáno výše o omezení virtuálního paměťového jednotlivých aplikací a 64 bit kernel to nezachrání, protože má podobné omezení pro 32 bit aplikace. I když to může pomoct a problém (na čas) vyřešit, protože u 32 bit kernelu má 32 bit binárka omezení na 3 GB, zatímco s 64 bit kernelem má omezení na 4 GB. Aby mohly aplikace využívat více, musejí být také 64 bit.
Neomlouvam se. Co je to za hovadinu?
Nainstaluje 64bit kernel,64bit userspace binarky/libky, 64bit javu a mozna i ty dalsi kompotenty v 64bitu. Worst case si prehistoricky verze zkompiluje. Nema zadny nenahraditelny binarni blob az na ten java bytecode jehoz spousteni vyresi instalaci 64bit javy. Co resis? Co furt resis za hypoteticky hovadiny ? Nepomahas.
-
Problém je v tom, že tam máš 32-bitový kernel (pozná se to podle "LowTotal: 387148 kB"). Celý počítač má sice 64GB paměti, ale v 32-bitovém módu je možno namapovat maximálně 4GB, z čehož 3GB jsou použity pro userspace a 1GB pro kernel. Ka každé stránce je potřeba mít alokovanou strukturu page (a někdy i další, např. buffer_head), tyto struktury se alokují z té zbylé 1GB - takže čím víc paměti v tom systému máš, tím větší část té přímo namapované 1GB je obsazena a tím větší je pravděpodobnost, že dojde k OOM. V té dolní paměti ti tam zbylo pouze 387MB, což moc není.
Řešení:
- použít 64-bitový kernel (klidně můžeš nechat existující 32-bit userspace), to ten problém definitivně vyřeší, protože 64-bitový kernel může přímo přistupovat k celé 64GB RAM.
Pokud procesor není 64-bitový, tak
- zvětšit množství paměti pro jádro a zmenšit množství paměti pro userspace - v konfiguraci kernelu v menu "General Setup" zaškrtneš "Configure standard kernel features (expert users)", pak se v menu"Processor type and features" objeví položka "Memory split" a tu nastavíš na 2G/2G. Můžeš tam nastavit i 1G/3G, ale to omezí velikost každého procesu na 1GB, takže je to použitelné pouze, pokud tam máš všechny procesy menší než 1G (zkontrolovat položku VIRT v příkazu top).
- pokud se ti nechce kompilovat kernel, tak je řešení jednoduché - ubrat tomu počítači pamět, dejme tomu na 4 nebo 8GB. Pak by se ta položka LowTotal měla zvětšit a pravděpodobnost vyvolání OOM killeru se tím zmenší.
-
- pokud se ti nechce kompilovat kernel, tak je řešení jednoduché - ubrat tomu počítači pamět, dejme tomu na 4 nebo 8GB. Pak by se ta položka LowTotal měla zvětšit a pravděpodobnost vyvolání OOM killeru se tím zmenší.
Ha, to je dobrý, méně je někdy více :)
-
stejne to dlouhodobe vidim na nutnost toho 64b kernelu
Prošel jsem celou diskuzi a nevšiml jsem si, že by tazatel dodal informaci o tom, jestli má 64 bit kernel nebo 32 bit s PAE. Pokud je to druhá možnost, platí co bylo napsáno výše o omezení virtuálního paměťového jednotlivých aplikací a 64 bit kernel to nezachrání, protože má podobné omezení pro 32 bit aplikace. I když to může pomoct a problém (na čas) vyřešit, protože u 32 bit kernelu má 32 bit binárka omezení na 3 GB, zatímco s 64 bit kernelem má omezení na 4 GB. Aby mohly aplikace využívat více, musejí být také 64 bit.
Neomlouvam se. Co je to za hovadinu?
Nainstaluje 64bit kernel,64bit userspace binarky/libky, 64bit javu a mozna i ty dalsi kompotenty v 64bitu. Worst case si prehistoricky verze zkompiluje. Nema zadny nenahraditelny binarni blob az na ten java bytecode jehoz spousteni vyresi instalaci 64bit javy. Co resis? Co furt resis za hypoteticky hovadiny ? Nepomahas.
Dle mého názoru říkám to samé jako ty, akorát tazatele upozorňuju na problémy s omezeními, kdyby se chtěl vydat jinou cestou než 64 bit kernel a 64 bit userland, protože se mi zdá, že to nechápe a řešení typu "nic neměnit" mu nepomůže ani kdyby se posunul na 64 bit kernel, jak mu tu radili.
Tak by možná bylo fajn, kdyby ses zklidnil a/nebo sis vzal zapomenuté medikamenty...
-
nejako sa to tu rozbehlo - ale k veci.
kernel : System uname: Linux-2.6.27-gentoo-r8-i686-Intel-R-_Xeon-R-_CPU_E5420_@_2.50GHz-with-gentoo-1.12.11.1
to ci je pae neviem explicitne identifikovat ale ked vidi 64GB asi ano.
hlavne aplikacie su 32bit takze
prehistoricka java jrockit-jdk-bin-4.0.0/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV)
/usr/sbin/mysqld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV)
-ad konzerva: diery ani ine nebezpecnosti nikoho nezaujimaju v "opustenom systeme" t.j. konzerve ktory je navyse izolovany aj mimo beznych pouzivatelov. Pouziva sa iba narazovo 2dni do mesiaca. takze z tohto pohladu chapem zakaznika ze toho nechce vrtat.
nie som specialista ani sa velmi nepohybujem vo vnutornostiach linux-u. Preto ocenujem rady a vysvetlenie ohladom problematiky 32bit procesov.
za mna vidim 1 riesenie
- znizit fyzicku pamat v systeme na rozumnych 8GB
- znizit pamatove naroky hlavnych aplikacii tak aby sa som sa dostal pod 2GB alebo mozem ist na 3GB ?
- odsledovat heap javy ako sa pohybuje pri zatazeni a zladit sizing procesov na limit z predosleho riadku
- pravidelny restart servera aby nestihlo dojst k vysokemu cerpaniu pamate
-
tak bylo by lepsi omezit procesy na 2G a 2G dat jadru - jak homo tu rikal pres memory split, to by se ale musel prekompilovat
v tom pripade by uz bylo lepsi prekompilovat jadro na 64bit a pak tam muze v klidu zustat 64GB pameti
nekomu se to tu nezdalo, ale je to mensi zasah, nez prekopat uplne vsechno na 64bit a bych si tipoval, ze ty OOM zmizi
-
jinak ty pameti nemusis fyzicky vytahovat, kernel ma parametr
mem=8192M
-
kernel : System uname: Linux-2.6.27-gentoo-r8-i686-Intel-R-_Xeon-R-_CPU_E5420_@_2.50GHz-with-gentoo-1.12.11.1
to ci je pae neviem explicitne identifikovat ale ked vidi 64GB asi ano.
prehistoricka java jrockit-jdk-bin-4.0.0/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV)
Ma ta java nejake heap limity? IMHO java moze vidiet teoreticky 64GB pamate pre heap (realne kazda verzia javy ma inu defaultnu heap politiku), avsak asi 32-bit java binarka realne bude mat problem s pouzitim 64GB.
-
IMHO java moze vidiet teoreticky 64GB pamate pre heap
Co má znamenat, že (32b) proces „vidí“ 64 GB paměti?
-
IMHO java moze vidiet teoreticky 64GB pamate pre heap
Co má znamenat, že (32b) proces „vidí“ 64 GB paměti?
Co proces nevidi kernel neboli!