Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
IOWait Problem
37 views
Skip to first unread message
Markus Schulz
Oct 17, 2012, 1:10:02 PM10/17/12
to
Moin,
wir haben in der Firma einen Debian/Squeeze Rechner der von Zeit zu
Zeit sehr hohes IOWait erzeugt und anschließend dann durch den darauf
laufenden JBoss EAP5 auch ein sehr hohes Load. Daraus resultiert dann
eine extrem schlechte Performance der EAP-Anwendung.
Der jboss läuft mit sun-jdk und folgenden JVM-Speicher Settings:
-Xms12500m -Xmx12500m -XX:MaxPermSize=512m
Ich habe hänge mal einen sysstat Auszug von so einem Fall mit an, die
kritische Zeit ist 15:35 Uhr, um 15:45Uhr wurde der jboss restarted,
daher die Menge an freiem Speicher ab diesem Zeitpunkt.
Was mich besonders wundert ist der große Anstieg an pgpgin/s.
Laut manpage sind das kbytes-pages/s die das System von Disk liest,
ergo vom Swap?
Warum ist dann aber der Wert für pswpin/s pswpout/s so niedrig und die
Swapnutzung allgemein?
Als erstes werde ich wohl den Swap deaktivieren. Hat sonst noch jemand
eine Idee was der Rechner hier so treibt?
# sar -p -rRqbBdSuwW -s 14:00:00 -e 18:00:00
Linux 2.6.32-5-amd64 (theodosius-ii) 17.10.2012 _x86_64_
(8 CPU)
14:05:01 CPU %user %nice %system %iowait %steal
%idle
14:15:01 all 6,40 0,00 0,54 2,04 0,00
91,02
14:25:01 all 4,91 0,00 0,43 1,61 0,00
93,05
14:35:01 all 5,21 0,00 0,48 1,80 0,00
92,51
14:45:01 all 4,45 0,00 0,41 1,29 0,00
93,85
14:55:01 all 4,31 0,00 0,44 1,52 0,00
93,74
15:05:01 all 4,88 0,00 0,43 1,70 0,00
92,99
15:15:01 all 4,57 0,00 0,44 1,60 0,00
93,39
15:25:01 all 4,44 0,00 0,40 1,37 0,00
93,79
15:35:02 all 5,50 0,00 1,17 68,50 0,00
24,83
15:45:01 all 14,77 0,00 2,10 31,77 0,00
51,37
15:55:02 all 6,07 0,00 0,45 2,12 0,00
91,36
16:05:01 all 5,20 0,00 0,61 2,01 0,00
92,18
16:15:01 all 5,10 0,00 0,33 1,10 0,00
93,47
16:25:01 all 5,42 0,00 0,40 1,50 0,00
92,69
16:35:01 all 4,67 0,00 0,36 1,39 0,00
93,58
16:45:01 all 3,84 0,00 0,28 0,99 0,00
94,88
16:55:01 all 4,93 0,00 0,36 1,61 0,00
93,10
17:05:01 all 4,77 0,00 0,40 1,80 0,00
93,03
17:15:01 all 4,63 0,00 0,33 1,32 0,00
93,73
17:25:01 all 3,26 0,00 0,28 1,33 0,00
95,14
17:35:01 all 2,69 0,00 0,33 2,18 0,00
94,80
17:45:01 all 2,87 0,00 0,20 0,68 0,00
96,24
17:55:01 all 3,09 0,00 0,28 1,44 0,00
95,19
Durchschn.: all 5,04 0,00 0,50 5,77 0,00
88,69
14:05:01 proc/s cswch/s
14:15:01 46,38 1651,56
14:25:01 37,51 1425,94
14:35:01 37,41 1453,27
14:45:01 32,90 1288,79
14:55:01 34,60 1364,16
15:05:01 35,51 1408,11
15:15:01 33,93 1314,47
15:25:01 30,69 1258,77
15:35:02 113,05 4081,97
15:45:01 303,83 9054,88
15:55:02 37,85 1534,63
16:05:01 55,41 1729,72
16:15:01 32,62 1333,07
16:25:01 42,26 1609,79
16:35:01 39,21 1462,45
16:45:01 30,25 1173,36
16:55:01 40,18 1510,24
17:05:01 44,07 1658,46
17:15:01 36,01 1345,88
17:25:01 30,44 1273,61
17:35:01 36,94 1670,64
17:45:01 19,90 904,17
17:55:01 29,40 1332,94
Durchschn.: 51,31 1862,52
14:05:01 pswpin/s pswpout/s
14:15:01 0,00 0,00
14:25:01 0,00 0,00
14:35:01 0,00 0,00
14:45:01 0,00 0,00
14:55:01 0,00 0,00
15:05:01 0,00 0,00
15:15:01 0,01 0,00
15:25:01 0,00 0,00
15:35:02 0,01 0,00
15:45:01 0,38 0,03
15:55:02 0,01 0,00
16:05:01 0,17 0,00
16:15:01 0,00 0,00
16:25:01 0,00 0,00
16:35:01 0,00 0,00
16:45:01 0,00 0,00
16:55:01 0,00 0,00
17:05:01 0,00 0,00
17:15:01 0,00 0,00
17:25:01 0,00 0,00
17:35:01 0,00 0,00
17:45:01 0,08 0,00
17:55:01 0,00 0,00
Durchschn.: 0,03 0,00
14:05:01 pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s
pgscand/s pgsteal/s %vmeff
14:15:01 3,97 499,94 1343,18 0,01 1050,67 22,93
0,00 21,76 94,88
14:25:01 3,28 413,38 1267,09 0,00 939,84 28,80
0,00 27,52 95,56
14:35:01 3,25 408,05 1244,56 0,01 943,34 32,14
0,00 31,38 97,66
14:45:01 4,47 357,73 1207,43 0,00 849,99 0,00
0,00 0,00 0,00
14:55:01 2,87 380,97 1238,77 0,00 896,71 14,40
0,00 13,81 95,93
15:05:01 7,51 398,05 1243,23 0,01 931,45 22,03
0,00 20,91 94,92
15:15:01 4,94 397,03 1231,90 0,05 894,47 20,53
0,00 19,53 95,11
15:25:01 9,25 349,27 1256,68 0,10 925,90 47,26
0,00 46,50 98,40
15:35:02 2674,15 591,19 1765,48 0,27 2204,80 604,31
25,38 611,91 97,18
15:45:01 1357,10 1297,74 6129,43 0,84 10295,62 136,42
131,22 245,03 91,55
15:55:02 154,44 769,30 3598,76 0,76 1724,55 0,00
0,00 0,00 0,00
16:05:01 82,69 774,84 7421,37 0,37 2894,61 0,00
0,00 0,00 0,00
16:15:01 22,62 301,03 1439,21 0,00 882,90 0,00
0,00 0,00 0,00
16:25:01 6,10 376,54 1556,68 0,00 1032,10 0,00
0,00 0,00 0,00
16:35:01 6,00 347,75 1433,84 0,00 933,25 0,00
0,00 0,00 0,00
16:45:01 5,57 274,74 1303,60 0,00 849,14 0,00
0,00 0,00 0,00
16:55:01 5,73 390,06 1339,76 0,00 1000,01 0,00
0,00 0,00 0,00
17:05:01 6,23 458,28 1442,22 0,00 995,62 0,00
0,00 0,00 0,00
17:15:01 3,27 387,65 1427,55 0,00 932,74 0,00
0,00 0,00 0,00
17:25:01 1,25 343,51 1371,31 0,00 852,13 0,00
0,00 0,00 0,00
17:35:01 0,62 427,99 1332,02 0,00 908,71 0,00
0,00 0,00 0,00
17:45:01 50,62 228,54 1154,15 0,05 696,13 0,00
0,00 0,00 0,00
17:55:01 4,81 348,66 1256,96 0,03 836,50 0,00
0,00 0,00 0,00
Durchschn.: 192,41 457,44 1912,65 0,11 1498,28 40,44
6,80 45,20 95,67
14:05:01 tps rtps wtps bread/s bwrtn/s
14:15:01 27,17 0,42 26,74 7,93 999,88
14:25:01 24,17 0,31 23,86 6,56 826,76
14:35:01 24,26 0,32 23,94 6,49 816,11
14:45:01 20,17 0,39 19,77 8,95 715,44
14:55:01 21,84 0,25 21,59 5,73 761,96
15:05:01 23,09 0,55 22,54 15,01 796,09
15:15:01 22,41 0,30 22,11 9,88 794,07
15:25:01 21,31 1,11 20,20 18,51 698,54
15:35:02 246,21 221,52 24,69 5346,79 1158,73
15:45:01 157,22 126,51 30,71 2715,72 2619,21
15:55:02 34,82 11,45 23,37 308,88 1538,62
16:05:01 32,02 7,49 24,53 165,39 1549,68
16:15:01 15,85 1,21 14,64 45,24 602,06
16:25:01 19,67 0,62 19,05 12,20 753,08
16:35:01 17,98 0,46 17,52 12,00 695,50
16:45:01 14,96 1,11 13,86 11,13 549,46
16:55:01 20,74 0,69 20,04 11,48 780,13
17:05:01 23,71 0,53 23,17 12,45 916,57
17:15:01 19,31 0,27 19,04 6,55 775,29
17:25:01 18,56 0,13 18,43 2,51 687,02
17:35:01 27,28 0,08 27,20 1,24 855,99
17:45:01 13,51 1,71 11,79 101,24 457,06
17:55:01 19,96 0,22 19,74 9,61 697,32
Durchschn.: 37,68 16,44 21,24 384,82 914,88
14:05:01 frmpg/s bufpg/s campg/s
14:15:01 -5,66 0,79 4,56
14:25:01 8,23 -0,08 -8,98
14:35:01 16,31 -1,15 -12,39
14:45:01 -20,63 0,82 18,01
14:55:01 -4,17 0,44 3,88
15:05:01 3,62 0,20 -3,25
15:15:01 -1,13 0,24 0,44
15:25:01 27,87 -0,74 -26,36
15:35:02 -39,96 -9,14 67,36
15:45:01 3499,04 14,01 -92,16
15:55:02 -349,87 -70,41 136,57
16:05:01 -274,57 7,25 88,38
16:15:01 -236,99 6,72 21,92
16:25:01 -212,99 7,59 21,71
16:35:01 -172,50 5,56 17,90
16:45:01 -103,47 4,66 15,71
16:55:01 -25,85 4,97 18,53
17:05:01 -143,29 4,49 24,05
17:15:01 -171,62 2,92 18,15
17:25:01 -144,62 2,51 14,38
17:35:01 -78,76 3,37 10,56
17:45:01 -71,48 1,10 22,96
17:55:01 -44,08 1,75 18,54
Durchschn.: 63,03 -0,53 16,55
14:05:01 kbmemfree kbmemused %memused kbbuffers kbcached kbcommit
%commit
14:15:01 107832 16363460 99,35 162796 809300 14976404
77,12
14:25:01 127584 16343708 99,23 162600 787740 14967640
77,08
14:35:01 166724 16304568 98,99 159832 758008 14942380
76,95
14:45:01 117208 16354084 99,29 161812 801228 14996204
77,22
14:55:01 107192 16364100 99,35 162880 810552 14956200
77,02
15:05:01 115892 16355400 99,30 163356 802748 14956892
77,02
15:15:01 113180 16358112 99,31 163928 803812 14981480
77,15
15:25:01 180080 16291212 98,91 162152 740552 14962260
77,05
15:35:02 83948 16387344 99,49 140164 902612 15022744
77,36
15:45:01 8472136 7999156 48,56 173760 681680 13902536
71,59
15:55:02 7632376 8838916 53,66 4756 1009464 14173556
72,99
16:05:01 6974480 9496812 57,66 22136 1221228 14177900
73,01
16:15:01 6405676 10065616 61,11 38268 1273848 14174000
72,99
16:25:01 5894472 10576820 64,21 56492 1325956 14195320
73,10
16:35:01 5480476 10990816 66,73 69844 1368920 14227872
73,27
16:45:01 5232140 11239152 68,23 81020 1406624 14215960
73,21
16:55:01 5170088 11301204 68,61 92940 1451092 14292916
73,60
17:05:01 4826172 11645120 70,70 103712 1508816 14281828
73,54
17:15:01 4414272 12057020 73,20 110728 1552372 14255244
73,41
17:25:01 4067184 12404108 75,31 116752 1586884 14242796
73,34
17:35:01 3878148 12593144 76,46 124836 1612240 14255244
73,41
17:45:01 3706588 12764704 77,50 127488 1667336 14268256
73,48
17:55:01 3600796 12870496 78,14 131684 1711840 14324320
73,76
Durchschn.: 3342376 13128916 79,71 117128 1156298 14510867
74,72
14:05:01 kbswpfree kbswpused %swpused kbswpcad %swpcad
14:15:01 2928824 19064 0,65 7196 37,75
14:25:01 2928824 19064 0,65 7196 37,75
14:35:01 2928824 19064 0,65 7196 37,75
14:45:01 2928824 19064 0,65 7196 37,75
14:55:01 2928824 19064 0,65 7196 37,75
15:05:01 2928824 19064 0,65 7188 37,70
15:15:01 2928824 19064 0,65 7068 37,08
15:25:01 2928824 19064 0,65 7068 37,08
15:35:02 2928824 19064 0,65 7104 37,26
15:45:01 2931284 16604 0,56 7036 42,38
15:55:02 2931296 16592 0,56 7040 42,43
16:05:01 2931460 16428 0,56 7292 44,39
16:15:01 2931460 16428 0,56 7292 44,39
16:25:01 2931460 16428 0,56 7292 44,39
16:35:01 2931460 16428 0,56 7292 44,39
16:45:01 2931460 16428 0,56 7292 44,39
16:55:01 2931460 16428 0,56 7292 44,39
17:05:01 2931460 16428 0,56 7292 44,39
17:15:01 2931460 16428 0,56 7292 44,39
17:25:01 2931460 16428 0,56 7292 44,39
17:35:01 2931460 16428 0,56 7292 44,39
17:45:01 2931540 16348 0,55 7404 45,29
17:55:01 2931540 16348 0,55 7404 45,29
Durchschn.: 2930421 17467 0,59 7226 41,37
14:05:01 runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15
14:15:01 0 924 0,78 0,71 0,61
14:25:01 1 935 0,36 0,46 0,54
14:35:01 1 894 0,24 0,46 0,51
14:45:01 0 977 0,64 0,48 0,49
14:55:01 0 939 0,55 0,42 0,43
15:05:01 0 907 0,49 0,68 0,55
15:15:01 3 933 0,75 0,56 0,52
15:25:01 0 943 0,21 0,33 0,43
15:35:02 1 992 119,50 99,27 51,16
15:45:01 2 673 1,60 35,23 46,08
15:55:02 1 840 0,97 5,45 24,48
16:05:01 1 843 0,39 1,12 13,11
16:15:01 2 814 0,48 0,58 7,08
16:25:01 0 827 0,25 0,46 3,95
16:35:01 0 845 0,70 0,71 2,38
16:45:01 0 847 0,28 0,31 1,36
16:55:01 1 903 0,49 0,44 0,90
17:05:01 1 902 0,49 0,58 0,75
17:15:01 2 864 0,37 0,46 0,60
17:25:01 0 864 0,25 0,31 0,46
17:35:01 0 877 0,61 0,64 0,52
17:45:01 1 896 0,10 0,28 0,38
17:55:01 0 895 0,40 0,31 0,34
Durchschn.: 1 884 5,69 6,53 6,85
14:05:01 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz
await svctm %util
14:15:01 sda 27,17 7,93 999,88 37,10 5,26
193,43 6,16 16,72
14:25:01 sda 24,17 6,56 826,76 34,47 4,19
173,33 6,21 15,01
14:35:01 sda 24,26 6,49 816,11 33,91 4,71
194,30 6,26 15,18
14:45:01 sda 20,17 8,95 715,44 35,92 3,48
172,44 6,13 12,36
14:55:01 sda 21,84 5,73 761,96 35,15 4,01
183,44 6,27 13,69
15:05:01 sda 23,09 15,01 796,09 35,12 4,25
184,25 6,27 14,48
15:15:01 sda 22,41 9,88 794,07 35,88 4,43
197,53 6,25 14,01
15:25:01 sda 21,31 18,51 698,54 33,65 3,71
174,15 6,20 13,22
15:35:02 sda 246,21 5346,79 1158,73 26,42 140,06
561,76 3,95 97,26
15:45:01 sda 157,22 2715,72 2619,21 33,93 92,53
599,35 4,02 63,17
15:55:02 sda 34,82 308,88 1538,62 53,06 3,54
101,56 5,01 17,45
16:05:01 sda 32,02 165,39 1549,68 53,56 2,61
81,54 5,50 17,61
16:05:01 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz
await svctm %util
16:15:01 sda 15,85 45,24 602,06 40,84 0,79
49,72 6,88 10,91
16:25:01 sda 19,67 12,20 753,08 38,91 1,04
53,09 7,13 14,02
16:35:01 sda 17,98 12,00 695,50 39,35 1,03
57,49 7,15 12,86
16:45:01 sda 14,96 11,13 549,46 37,46 1,05
70,07 6,71 10,05
16:55:01 sda 20,74 11,48 780,13 38,18 2,19
105,62 7,00 14,51
17:05:01 sda 23,71 12,45 916,57 39,19 2,95
124,62 6,90 16,36
17:15:01 sda 19,31 6,55 775,29 40,48 2,60
134,66 6,68 12,91
17:25:01 sda 18,56 2,51 687,02 37,15 2,13
114,93 6,88 12,77
17:35:01 sda 27,28 1,24 855,99 31,42 2,92
106,84 7,16 19,53
17:45:01 sda 13,51 101,24 457,06 41,34 1,50
111,07 5,76 7,78
17:55:01 sda 19,96 9,61 697,32 35,42 2,35
117,60 6,82 13,62
Durchschn.: sda 37,68 384,82 914,88 34,50 12,76
338,68 5,26 19,81
--
Markus Schulz
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/ee6b4c6c9479af79...@mail.tastatur-junkie.de
wir haben in der Firma einen Debian/Squeeze Rechner der von Zeit zu
Zeit sehr hohes IOWait erzeugt und anschließend dann durch den darauf
laufenden JBoss EAP5 auch ein sehr hohes Load. Daraus resultiert dann
eine extrem schlechte Performance der EAP-Anwendung.
Der jboss läuft mit sun-jdk und folgenden JVM-Speicher Settings:
-Xms12500m -Xmx12500m -XX:MaxPermSize=512m
Ich habe hänge mal einen sysstat Auszug von so einem Fall mit an, die
kritische Zeit ist 15:35 Uhr, um 15:45Uhr wurde der jboss restarted,
daher die Menge an freiem Speicher ab diesem Zeitpunkt.
Was mich besonders wundert ist der große Anstieg an pgpgin/s.
Laut manpage sind das kbytes-pages/s die das System von Disk liest,
ergo vom Swap?
Warum ist dann aber der Wert für pswpin/s pswpout/s so niedrig und die
Swapnutzung allgemein?
Als erstes werde ich wohl den Swap deaktivieren. Hat sonst noch jemand
eine Idee was der Rechner hier so treibt?
# sar -p -rRqbBdSuwW -s 14:00:00 -e 18:00:00
Linux 2.6.32-5-amd64 (theodosius-ii) 17.10.2012 _x86_64_
(8 CPU)
14:05:01 CPU %user %nice %system %iowait %steal
%idle
14:15:01 all 6,40 0,00 0,54 2,04 0,00
91,02
14:25:01 all 4,91 0,00 0,43 1,61 0,00
93,05
14:35:01 all 5,21 0,00 0,48 1,80 0,00
92,51
14:45:01 all 4,45 0,00 0,41 1,29 0,00
93,85
14:55:01 all 4,31 0,00 0,44 1,52 0,00
93,74
15:05:01 all 4,88 0,00 0,43 1,70 0,00
92,99
15:15:01 all 4,57 0,00 0,44 1,60 0,00
93,39
15:25:01 all 4,44 0,00 0,40 1,37 0,00
93,79
15:35:02 all 5,50 0,00 1,17 68,50 0,00
24,83
15:45:01 all 14,77 0,00 2,10 31,77 0,00
51,37
15:55:02 all 6,07 0,00 0,45 2,12 0,00
91,36
16:05:01 all 5,20 0,00 0,61 2,01 0,00
92,18
16:15:01 all 5,10 0,00 0,33 1,10 0,00
93,47
16:25:01 all 5,42 0,00 0,40 1,50 0,00
92,69
16:35:01 all 4,67 0,00 0,36 1,39 0,00
93,58
16:45:01 all 3,84 0,00 0,28 0,99 0,00
94,88
16:55:01 all 4,93 0,00 0,36 1,61 0,00
93,10
17:05:01 all 4,77 0,00 0,40 1,80 0,00
93,03
17:15:01 all 4,63 0,00 0,33 1,32 0,00
93,73
17:25:01 all 3,26 0,00 0,28 1,33 0,00
95,14
17:35:01 all 2,69 0,00 0,33 2,18 0,00
94,80
17:45:01 all 2,87 0,00 0,20 0,68 0,00
96,24
17:55:01 all 3,09 0,00 0,28 1,44 0,00
95,19
Durchschn.: all 5,04 0,00 0,50 5,77 0,00
88,69
14:05:01 proc/s cswch/s
14:15:01 46,38 1651,56
14:25:01 37,51 1425,94
14:35:01 37,41 1453,27
14:45:01 32,90 1288,79
14:55:01 34,60 1364,16
15:05:01 35,51 1408,11
15:15:01 33,93 1314,47
15:25:01 30,69 1258,77
15:35:02 113,05 4081,97
15:45:01 303,83 9054,88
15:55:02 37,85 1534,63
16:05:01 55,41 1729,72
16:15:01 32,62 1333,07
16:25:01 42,26 1609,79
16:35:01 39,21 1462,45
16:45:01 30,25 1173,36
16:55:01 40,18 1510,24
17:05:01 44,07 1658,46
17:15:01 36,01 1345,88
17:25:01 30,44 1273,61
17:35:01 36,94 1670,64
17:45:01 19,90 904,17
17:55:01 29,40 1332,94
Durchschn.: 51,31 1862,52
14:05:01 pswpin/s pswpout/s
14:15:01 0,00 0,00
14:25:01 0,00 0,00
14:35:01 0,00 0,00
14:45:01 0,00 0,00
14:55:01 0,00 0,00
15:05:01 0,00 0,00
15:15:01 0,01 0,00
15:25:01 0,00 0,00
15:35:02 0,01 0,00
15:45:01 0,38 0,03
15:55:02 0,01 0,00
16:05:01 0,17 0,00
16:15:01 0,00 0,00
16:25:01 0,00 0,00
16:35:01 0,00 0,00
16:45:01 0,00 0,00
16:55:01 0,00 0,00
17:05:01 0,00 0,00
17:15:01 0,00 0,00
17:25:01 0,00 0,00
17:35:01 0,00 0,00
17:45:01 0,08 0,00
17:55:01 0,00 0,00
Durchschn.: 0,03 0,00
14:05:01 pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s
pgscand/s pgsteal/s %vmeff
14:15:01 3,97 499,94 1343,18 0,01 1050,67 22,93
0,00 21,76 94,88
14:25:01 3,28 413,38 1267,09 0,00 939,84 28,80
0,00 27,52 95,56
14:35:01 3,25 408,05 1244,56 0,01 943,34 32,14
0,00 31,38 97,66
14:45:01 4,47 357,73 1207,43 0,00 849,99 0,00
0,00 0,00 0,00
14:55:01 2,87 380,97 1238,77 0,00 896,71 14,40
0,00 13,81 95,93
15:05:01 7,51 398,05 1243,23 0,01 931,45 22,03
0,00 20,91 94,92
15:15:01 4,94 397,03 1231,90 0,05 894,47 20,53
0,00 19,53 95,11
15:25:01 9,25 349,27 1256,68 0,10 925,90 47,26
0,00 46,50 98,40
15:35:02 2674,15 591,19 1765,48 0,27 2204,80 604,31
25,38 611,91 97,18
15:45:01 1357,10 1297,74 6129,43 0,84 10295,62 136,42
131,22 245,03 91,55
15:55:02 154,44 769,30 3598,76 0,76 1724,55 0,00
0,00 0,00 0,00
16:05:01 82,69 774,84 7421,37 0,37 2894,61 0,00
0,00 0,00 0,00
16:15:01 22,62 301,03 1439,21 0,00 882,90 0,00
0,00 0,00 0,00
16:25:01 6,10 376,54 1556,68 0,00 1032,10 0,00
0,00 0,00 0,00
16:35:01 6,00 347,75 1433,84 0,00 933,25 0,00
0,00 0,00 0,00
16:45:01 5,57 274,74 1303,60 0,00 849,14 0,00
0,00 0,00 0,00
16:55:01 5,73 390,06 1339,76 0,00 1000,01 0,00
0,00 0,00 0,00
17:05:01 6,23 458,28 1442,22 0,00 995,62 0,00
0,00 0,00 0,00
17:15:01 3,27 387,65 1427,55 0,00 932,74 0,00
0,00 0,00 0,00
17:25:01 1,25 343,51 1371,31 0,00 852,13 0,00
0,00 0,00 0,00
17:35:01 0,62 427,99 1332,02 0,00 908,71 0,00
0,00 0,00 0,00
17:45:01 50,62 228,54 1154,15 0,05 696,13 0,00
0,00 0,00 0,00
17:55:01 4,81 348,66 1256,96 0,03 836,50 0,00
0,00 0,00 0,00
Durchschn.: 192,41 457,44 1912,65 0,11 1498,28 40,44
6,80 45,20 95,67
14:05:01 tps rtps wtps bread/s bwrtn/s
14:15:01 27,17 0,42 26,74 7,93 999,88
14:25:01 24,17 0,31 23,86 6,56 826,76
14:35:01 24,26 0,32 23,94 6,49 816,11
14:45:01 20,17 0,39 19,77 8,95 715,44
14:55:01 21,84 0,25 21,59 5,73 761,96
15:05:01 23,09 0,55 22,54 15,01 796,09
15:15:01 22,41 0,30 22,11 9,88 794,07
15:25:01 21,31 1,11 20,20 18,51 698,54
15:35:02 246,21 221,52 24,69 5346,79 1158,73
15:45:01 157,22 126,51 30,71 2715,72 2619,21
15:55:02 34,82 11,45 23,37 308,88 1538,62
16:05:01 32,02 7,49 24,53 165,39 1549,68
16:15:01 15,85 1,21 14,64 45,24 602,06
16:25:01 19,67 0,62 19,05 12,20 753,08
16:35:01 17,98 0,46 17,52 12,00 695,50
16:45:01 14,96 1,11 13,86 11,13 549,46
16:55:01 20,74 0,69 20,04 11,48 780,13
17:05:01 23,71 0,53 23,17 12,45 916,57
17:15:01 19,31 0,27 19,04 6,55 775,29
17:25:01 18,56 0,13 18,43 2,51 687,02
17:35:01 27,28 0,08 27,20 1,24 855,99
17:45:01 13,51 1,71 11,79 101,24 457,06
17:55:01 19,96 0,22 19,74 9,61 697,32
Durchschn.: 37,68 16,44 21,24 384,82 914,88
14:05:01 frmpg/s bufpg/s campg/s
14:15:01 -5,66 0,79 4,56
14:25:01 8,23 -0,08 -8,98
14:35:01 16,31 -1,15 -12,39
14:45:01 -20,63 0,82 18,01
14:55:01 -4,17 0,44 3,88
15:05:01 3,62 0,20 -3,25
15:15:01 -1,13 0,24 0,44
15:25:01 27,87 -0,74 -26,36
15:35:02 -39,96 -9,14 67,36
15:45:01 3499,04 14,01 -92,16
15:55:02 -349,87 -70,41 136,57
16:05:01 -274,57 7,25 88,38
16:15:01 -236,99 6,72 21,92
16:25:01 -212,99 7,59 21,71
16:35:01 -172,50 5,56 17,90
16:45:01 -103,47 4,66 15,71
16:55:01 -25,85 4,97 18,53
17:05:01 -143,29 4,49 24,05
17:15:01 -171,62 2,92 18,15
17:25:01 -144,62 2,51 14,38
17:35:01 -78,76 3,37 10,56
17:45:01 -71,48 1,10 22,96
17:55:01 -44,08 1,75 18,54
Durchschn.: 63,03 -0,53 16,55
14:05:01 kbmemfree kbmemused %memused kbbuffers kbcached kbcommit
%commit
14:15:01 107832 16363460 99,35 162796 809300 14976404
77,12
14:25:01 127584 16343708 99,23 162600 787740 14967640
77,08
14:35:01 166724 16304568 98,99 159832 758008 14942380
76,95
14:45:01 117208 16354084 99,29 161812 801228 14996204
77,22
14:55:01 107192 16364100 99,35 162880 810552 14956200
77,02
15:05:01 115892 16355400 99,30 163356 802748 14956892
77,02
15:15:01 113180 16358112 99,31 163928 803812 14981480
77,15
15:25:01 180080 16291212 98,91 162152 740552 14962260
77,05
15:35:02 83948 16387344 99,49 140164 902612 15022744
77,36
15:45:01 8472136 7999156 48,56 173760 681680 13902536
71,59
15:55:02 7632376 8838916 53,66 4756 1009464 14173556
72,99
16:05:01 6974480 9496812 57,66 22136 1221228 14177900
73,01
16:15:01 6405676 10065616 61,11 38268 1273848 14174000
72,99
16:25:01 5894472 10576820 64,21 56492 1325956 14195320
73,10
16:35:01 5480476 10990816 66,73 69844 1368920 14227872
73,27
16:45:01 5232140 11239152 68,23 81020 1406624 14215960
73,21
16:55:01 5170088 11301204 68,61 92940 1451092 14292916
73,60
17:05:01 4826172 11645120 70,70 103712 1508816 14281828
73,54
17:15:01 4414272 12057020 73,20 110728 1552372 14255244
73,41
17:25:01 4067184 12404108 75,31 116752 1586884 14242796
73,34
17:35:01 3878148 12593144 76,46 124836 1612240 14255244
73,41
17:45:01 3706588 12764704 77,50 127488 1667336 14268256
73,48
17:55:01 3600796 12870496 78,14 131684 1711840 14324320
73,76
Durchschn.: 3342376 13128916 79,71 117128 1156298 14510867
74,72
14:05:01 kbswpfree kbswpused %swpused kbswpcad %swpcad
14:15:01 2928824 19064 0,65 7196 37,75
14:25:01 2928824 19064 0,65 7196 37,75
14:35:01 2928824 19064 0,65 7196 37,75
14:45:01 2928824 19064 0,65 7196 37,75
14:55:01 2928824 19064 0,65 7196 37,75
15:05:01 2928824 19064 0,65 7188 37,70
15:15:01 2928824 19064 0,65 7068 37,08
15:25:01 2928824 19064 0,65 7068 37,08
15:35:02 2928824 19064 0,65 7104 37,26
15:45:01 2931284 16604 0,56 7036 42,38
15:55:02 2931296 16592 0,56 7040 42,43
16:05:01 2931460 16428 0,56 7292 44,39
16:15:01 2931460 16428 0,56 7292 44,39
16:25:01 2931460 16428 0,56 7292 44,39
16:35:01 2931460 16428 0,56 7292 44,39
16:45:01 2931460 16428 0,56 7292 44,39
16:55:01 2931460 16428 0,56 7292 44,39
17:05:01 2931460 16428 0,56 7292 44,39
17:15:01 2931460 16428 0,56 7292 44,39
17:25:01 2931460 16428 0,56 7292 44,39
17:35:01 2931460 16428 0,56 7292 44,39
17:45:01 2931540 16348 0,55 7404 45,29
17:55:01 2931540 16348 0,55 7404 45,29
Durchschn.: 2930421 17467 0,59 7226 41,37
14:05:01 runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15
14:15:01 0 924 0,78 0,71 0,61
14:25:01 1 935 0,36 0,46 0,54
14:35:01 1 894 0,24 0,46 0,51
14:45:01 0 977 0,64 0,48 0,49
14:55:01 0 939 0,55 0,42 0,43
15:05:01 0 907 0,49 0,68 0,55
15:15:01 3 933 0,75 0,56 0,52
15:25:01 0 943 0,21 0,33 0,43
15:35:02 1 992 119,50 99,27 51,16
15:45:01 2 673 1,60 35,23 46,08
15:55:02 1 840 0,97 5,45 24,48
16:05:01 1 843 0,39 1,12 13,11
16:15:01 2 814 0,48 0,58 7,08
16:25:01 0 827 0,25 0,46 3,95
16:35:01 0 845 0,70 0,71 2,38
16:45:01 0 847 0,28 0,31 1,36
16:55:01 1 903 0,49 0,44 0,90
17:05:01 1 902 0,49 0,58 0,75
17:15:01 2 864 0,37 0,46 0,60
17:25:01 0 864 0,25 0,31 0,46
17:35:01 0 877 0,61 0,64 0,52
17:45:01 1 896 0,10 0,28 0,38
17:55:01 0 895 0,40 0,31 0,34
Durchschn.: 1 884 5,69 6,53 6,85
14:05:01 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz
await svctm %util
14:15:01 sda 27,17 7,93 999,88 37,10 5,26
193,43 6,16 16,72
14:25:01 sda 24,17 6,56 826,76 34,47 4,19
173,33 6,21 15,01
14:35:01 sda 24,26 6,49 816,11 33,91 4,71
194,30 6,26 15,18
14:45:01 sda 20,17 8,95 715,44 35,92 3,48
172,44 6,13 12,36
14:55:01 sda 21,84 5,73 761,96 35,15 4,01
183,44 6,27 13,69
15:05:01 sda 23,09 15,01 796,09 35,12 4,25
184,25 6,27 14,48
15:15:01 sda 22,41 9,88 794,07 35,88 4,43
197,53 6,25 14,01
15:25:01 sda 21,31 18,51 698,54 33,65 3,71
174,15 6,20 13,22
15:35:02 sda 246,21 5346,79 1158,73 26,42 140,06
561,76 3,95 97,26
15:45:01 sda 157,22 2715,72 2619,21 33,93 92,53
599,35 4,02 63,17
15:55:02 sda 34,82 308,88 1538,62 53,06 3,54
101,56 5,01 17,45
16:05:01 sda 32,02 165,39 1549,68 53,56 2,61
81,54 5,50 17,61
16:05:01 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz
await svctm %util
16:15:01 sda 15,85 45,24 602,06 40,84 0,79
49,72 6,88 10,91
16:25:01 sda 19,67 12,20 753,08 38,91 1,04
53,09 7,13 14,02
16:35:01 sda 17,98 12,00 695,50 39,35 1,03
57,49 7,15 12,86
16:45:01 sda 14,96 11,13 549,46 37,46 1,05
70,07 6,71 10,05
16:55:01 sda 20,74 11,48 780,13 38,18 2,19
105,62 7,00 14,51
17:05:01 sda 23,71 12,45 916,57 39,19 2,95
124,62 6,90 16,36
17:15:01 sda 19,31 6,55 775,29 40,48 2,60
134,66 6,68 12,91
17:25:01 sda 18,56 2,51 687,02 37,15 2,13
114,93 6,88 12,77
17:35:01 sda 27,28 1,24 855,99 31,42 2,92
106,84 7,16 19,53
17:45:01 sda 13,51 101,24 457,06 41,34 1,50
111,07 5,76 7,78
17:55:01 sda 19,96 9,61 697,32 35,42 2,35
117,60 6,82 13,62
Durchschn.: sda 37,68 384,82 914,88 34,50 12,76
338,68 5,26 19,81
--
Markus Schulz
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/ee6b4c6c9479af79...@mail.tastatur-junkie.de
Martin Steigerwald
Oct 17, 2012, 2:00:01 PM10/17/12
to
Am Mittwoch, 17. Oktober 2012 schrieb Markus Schulz:
> # sar -p -rRqbBdSuwW -s 14:00:00 -e 18:00:00
> Linux 2.6.32-5-amd64
> (theodosius-ii) 17.10.2012 _x86_64_ (8 CPU)
>
> 14:05:01 CPU %user %nice %system %iowait %steal
> %idle
> 14:15:01 all 6,40 0,00 0,54 2,04 0,00
> 91,02
> 14:25:01 all 4,91 0,00 0,43 1,61 0,00
> 93,05
> 14:35:01 all 5,21 0,00 0,48 1,80 0,00
Das ist ziemlich schlecht zu lesen. Ja, KMailhats jetzt nochmal
> # sar -p -rRqbBdSuwW -s 14:00:00 -e 18:00:00
> Linux 2.6.32-5-amd64
> (theodosius-ii) 17.10.2012 _x86_64_ (8 CPU)
>
> 14:05:01 CPU %user %nice %system %iowait %steal
> %idle
> 14:15:01 all 6,40 0,00 0,54 2,04 0,00
> 91,02
> 14:25:01 all 4,91 0,00 0,43 1,61 0,00
> 93,05
> 14:35:01 all 5,21 0,00 0,48 1,80 0,00
umgebrochen, ist aber für meine Antwort egal.
Ich bitte Dich, diese Angaben ohne Zeilenumbruch zu senden.
Zusätzlich fehlen eine ganze Reihe Angaben zum System selbst. Wie z.B. wo
es die Daten speichert, Hauptspeichermenge, CPU usw. Ja teilweise läßt
sich das aus den Sysstat-Daten rauslesen. Ich bitte dich aber, das ganze
etwas netter aufzubereiten, wenn du hier schon um kostenlosen Support für
einen Unternehmens-Server bittest.
Auch fehlt ein Blick auf die Prozesse.
Für einen recht netten Überblick empfehle ich atop zu verwenden. Das kann
I/O nach Prozess anzeigen.
Interessanterweise gleich dann, wenn das Problem auftritt.
Laut
> 14:05:01 kbmemfree kbmemused %memused
> kbbuffers kbcached kbcommit %commit
> 14:15:01 107832 16363460 99,35 162796 809300 14976404
> 77,12
> 14:25:01 127584 16343708 99,23 162600 787740 14967640
> 77,08
> 14:35:01 166724 16304568 98,99 159832 758008 14942380
> 76,95
Spalten vertan hab. Und das, was für Caches bereit steht, ziemlich
niedrig.
Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde ich
auch nicht ausschalten.
Daher würde mich auch interessieren, wer da wieviel physikalischen
Speicher belegt (annähernd Resident Set Size, RSS).
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Martin Steigerwald
Oct 17, 2012, 2:00:02 PM10/17/12
to
Am Mittwoch, 17. Oktober 2012 schrieb Martin Steigerwald:
> Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde
> ich auch nicht ausschalten.
>
> Daher würde mich auch interessieren, wer da wieviel physikalischen
> Speicher belegt (annähernd Resident Set Size, RSS).
Beziehungsweise auch Änderungen darin.
> Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde
> ich auch nicht ausschalten.
>
> Daher würde mich auch interessieren, wer da wieviel physikalischen
> Speicher belegt (annähernd Resident Set Size, RSS).
RGROW in atop z.B.
Für feingranularere Aufnahmen eignet sich auch collectd. atop hat halt den
Vorteil, dass man auch in den Aufzeichnungen via atopsar in Prozesse
reinschauen kann.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Martin Steigerwald
Oct 17, 2012, 4:30:02 PM10/17/12
to
Am Mittwoch, 17. Oktober 2012 schrieb Martin Steigerwald:
> Am Mittwoch, 17. Oktober 2012 schrieb Martin Steigerwald:
> > Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde
> > ich auch nicht ausschalten.
> >
> > Daher würde mich auch interessieren, wer da wieviel physikalischen
> > Speicher belegt (annähernd Resident Set Size, RSS).
>
> Beziehungsweise auch Änderungen darin.
>
> RGROW in atop z.B.
>
> Für feingranularere Aufnahmen eignet sich auch collectd. atop hat halt
> den Vorteil, dass man auch in den Aufzeichnungen via atopsar in
> Prozesse reinschauen kann.
Bzw. kann kann sogar mit atop selbst in Aufzeichnungen blättern.
> Am Mittwoch, 17. Oktober 2012 schrieb Martin Steigerwald:
> > Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde
> > ich auch nicht ausschalten.
> >
> > Daher würde mich auch interessieren, wer da wieviel physikalischen
> > Speicher belegt (annähernd Resident Set Size, RSS).
>
> Beziehungsweise auch Änderungen darin.
>
> RGROW in atop z.B.
>
> Für feingranularere Aufnahmen eignet sich auch collectd. atop hat halt
> den Vorteil, dass man auch in den Aufzeichnungen via atopsar in
> Prozesse reinschauen kann.
Schau Dir einfach mal Manpage und Homepage genauer an.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Markus Schulz
Oct 17, 2012, 5:00:03 PM10/17/12
to
Nabend,
Am Mittwoch, 17. Oktober 2012, 19:56:41 schrieb Martin Steigerwald:
> Das ist ziemlich schlecht zu lesen. Ja, KMailhats jetzt nochmal
> umgebrochen, ist aber für meine Antwort egal.
>
> Ich bitte Dich, diese Angaben ohne Zeilenumbruch zu senden.
hab sie einfach mal als text-attachment angehangen.
Roundcube konnte die format=flowed Mail problemlos darstellen.
KMail nutze ich seit dem akonadi Wahnsinn kaum noch ;)
> Zusätzlich fehlen eine ganze Reihe Angaben zum System selbst. Wie z.B. wo
> es die Daten speichert, Hauptspeichermenge, CPU usw. Ja teilweise läßt
> sich das aus den Sysstat-Daten rauslesen. Ich bitte dich aber, das ganze
> etwas netter aufzubereiten, wenn du hier schon um kostenlosen Support für
> einen Unternehmens-Server bittest.
- 8x Intel(R) Xeon(R) CPU X5365 @ 3.00GHz"
- 16GB Ram
- 10k 72GB Disks im HW-Raid1 (hier müsste ich den Admin fragen, bin eigentlich
nur für die Software im JBoss zuständig)
> Auch fehlt ein Blick auf die Prozesse.
auf der Kiste läuft sonst nix relevantes: ssh/ntpd/nagios-statd/nfs-
client/bacula-fd. Alles keine Speicherfresser....
mal aktuelle Daten um eine Vorstellung zu bekommen:
# ps -eo cputime,etime,pmem,rss,sz,vsz,comm | grep -v "^00:00"
TIME ELAPSED %MEM RSS SZ VSZ COMMAND
00:01:47 108-11:24:18 0.0 0 0 0 events/7
00:09:27 108-11:24:18 0.0 0 0 0 kswapd0
01:52:20 108-11:24:06 0.0 0 0 0 kjournald
00:01:07 108-11:24:05 0.0 0 0 0 edac-poller
00:06:01 108-11:24:03 0.0 0 0 0 flush-8:0
00:03:19 108-11:22:39 0.0 0 0 0 bond0
00:01:00 108-11:22:37 0.0 6092 8391 33564 nagios-statd
00:03:08 108-11:22:37 0.0 1024 8533 34132 ntpd
00:49:26 108-11:22:36 0.0 3384 38131 152524 bacula-fd
00:01:17 36-04:50:10 0.0 1116 29929 119716 rsyslogd
00:01:17 23-04:35:53 0.0 7236 11091 44364 munin-node
01:29:56 07:08:49 65.2 10747944 4430036 17720144 java
Der gesamte Speicher ist für den JBoss, der deshalb auch mit reservierten
12,5GB Heap und 512MB PermGen gestartet wird.
iotop und co. wurde bereits herangezogen. der jboss erzeugt keine große io-
Last (die lokale Platte enthält quasi keine Laufzeitdaten die cache-relevant
sind).
Man sieht nur kernel-threads mit hoher io-Last. (falls es ohne Swap nochmal
auftritt protokolliere ich das)
>
> Für einen recht netten Überblick empfehle ich atop zu verwenden. Das kann
> I/O nach Prozess anzeigen.
>
> Interessanterweise gleich dann, wenn das Problem auftritt.
> Laut
>
> > 14:05:01 kbmemfree kbmemused %memused
> > kbbuffers kbcached kbcommit %commit
> > 14:15:01 107832 16363460 99,35 162796 809300 14976404
> >
> > 77,12
eigentlich ausreichend. Wie gesagt da liegen keine relevanten Daten auf der
Platte die der JBoss braucht, die holt er aus dem Alfresco bzw. Postgresql.
Der Rechner hat auch in der restlichen Zeit keine nennenswerte IO-Last.
MfG
msc
Am Mittwoch, 17. Oktober 2012, 19:56:41 schrieb Martin Steigerwald:
> Das ist ziemlich schlecht zu lesen. Ja, KMailhats jetzt nochmal
> umgebrochen, ist aber für meine Antwort egal.
>
> Ich bitte Dich, diese Angaben ohne Zeilenumbruch zu senden.
Roundcube konnte die format=flowed Mail problemlos darstellen.
KMail nutze ich seit dem akonadi Wahnsinn kaum noch ;)
> Zusätzlich fehlen eine ganze Reihe Angaben zum System selbst. Wie z.B. wo
> es die Daten speichert, Hauptspeichermenge, CPU usw. Ja teilweise läßt
> sich das aus den Sysstat-Daten rauslesen. Ich bitte dich aber, das ganze
> etwas netter aufzubereiten, wenn du hier schon um kostenlosen Support für
> einen Unternehmens-Server bittest.
- 16GB Ram
- 10k 72GB Disks im HW-Raid1 (hier müsste ich den Admin fragen, bin eigentlich
nur für die Software im JBoss zuständig)
> Auch fehlt ein Blick auf die Prozesse.
client/bacula-fd. Alles keine Speicherfresser....
mal aktuelle Daten um eine Vorstellung zu bekommen:
# ps -eo cputime,etime,pmem,rss,sz,vsz,comm | grep -v "^00:00"
TIME ELAPSED %MEM RSS SZ VSZ COMMAND
00:01:47 108-11:24:18 0.0 0 0 0 events/7
00:09:27 108-11:24:18 0.0 0 0 0 kswapd0
01:52:20 108-11:24:06 0.0 0 0 0 kjournald
00:01:07 108-11:24:05 0.0 0 0 0 edac-poller
00:06:01 108-11:24:03 0.0 0 0 0 flush-8:0
00:03:19 108-11:22:39 0.0 0 0 0 bond0
00:01:00 108-11:22:37 0.0 6092 8391 33564 nagios-statd
00:03:08 108-11:22:37 0.0 1024 8533 34132 ntpd
00:49:26 108-11:22:36 0.0 3384 38131 152524 bacula-fd
00:01:17 36-04:50:10 0.0 1116 29929 119716 rsyslogd
00:01:17 23-04:35:53 0.0 7236 11091 44364 munin-node
01:29:56 07:08:49 65.2 10747944 4430036 17720144 java
Der gesamte Speicher ist für den JBoss, der deshalb auch mit reservierten
12,5GB Heap und 512MB PermGen gestartet wird.
iotop und co. wurde bereits herangezogen. der jboss erzeugt keine große io-
Last (die lokale Platte enthält quasi keine Laufzeitdaten die cache-relevant
sind).
Man sieht nur kernel-threads mit hoher io-Last. (falls es ohne Swap nochmal
auftritt protokolliere ich das)
>
> Für einen recht netten Überblick empfehle ich atop zu verwenden. Das kann
> I/O nach Prozess anzeigen.
>
> Interessanterweise gleich dann, wenn das Problem auftritt.
> Laut
>
> > 14:05:01 kbmemfree kbmemused %memused
> > kbbuffers kbcached kbcommit %commit
> > 14:15:01 107832 16363460 99,35 162796 809300 14976404
> >
> > 77,12
> ist die Speicherauslastung ziemlich hoch, wenn ich mich da nicht in den
> Spalten vertan hab. Und das, was für Caches bereit steht, ziemlich
> niedrig.
>
> Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde ich
> auch nicht ausschalten.
800MB cache und 160MB buffers-cache sind in meinen Augen für die Kiste
> Spalten vertan hab. Und das, was für Caches bereit steht, ziemlich
> niedrig.
>
> Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde ich
> auch nicht ausschalten.
eigentlich ausreichend. Wie gesagt da liegen keine relevanten Daten auf der
Platte die der JBoss braucht, die holt er aus dem Alfresco bzw. Postgresql.
Der Rechner hat auch in der restlichen Zeit keine nennenswerte IO-Last.
MfG
msc
Dirk Finkeldey
Oct 18, 2012, 6:40:02 AM10/18/12
to
> msc
Hm, ich habe ja nicht so viel Ahnung aber das einzige was laut deiner
Auflistung Last Verursacht ist Java.
03:35:02 PM all 5.50 0.00 1.17 68.50 0.00 24.83
03:45:01 PM all 14.77 0.00 2.10 31.77 0.00 51.37
Zu diesen 2 Zeilen hätte ich gerne mal die atop Auflistung gesehen, es scheint so als ob da jboss oder eine Komponente mächtig am System zehrt.
Gruß Dirk Finkeldey
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Markus Schulz
Oct 18, 2012, 7:50:02 AM10/18/12
to
Am Donnerstag, 18. Oktober 2012 schrieb Dirk Finkeldey:
> Hm, ich habe ja nicht so viel Ahnung aber das einzige was laut deiner
> Auflistung Last Verursacht ist Java.
>
> 03:35:02 PM all 5.50 0.00 1.17 68.50 0.00
> 24.83 03:45:01 PM all 14.77 0.00 2.10
> 31.77 0.00 51.37
Dort ist aber nur IO-Last zu sehen und die kommt _nicht_ vom JBoss.
> Hm, ich habe ja nicht so viel Ahnung aber das einzige was laut deiner
> Auflistung Last Verursacht ist Java.
>
> 03:35:02 PM all 5.50 0.00 1.17 68.50 0.00
> 24.83 03:45:01 PM all 14.77 0.00 2.10
> 31.77 0.00 51.37
User-Prozess-Last ist nur bei 5.5%.
Der JBoss treibt dann nur das Load in die Höhe da die Anfragen von Nutzern ja nicht
fertig werden und diese dann natürlich immer wieder klicken....
>
> Zu diesen 2 Zeilen hätte ich gerne mal die atop Auflistung gesehen,
> es scheint so als ob da jboss oder eine Komponente mächtig am System
> zehrt.
Und ich suche immer noch nach einer Erklärung
02:05:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
03:35:02 PM 2674.15 591.19 1765.48 0.27 2204.80 604.31 25.38 611.91 97.18
woher dieser große pgpgin/s Wert kommt bei einer Swap-Nutzung von:
02:05:01 PM kbswpfree kbswpused %swpused kbswpcad %swpcad
03:25:01 PM 2928824 19064 0.65 7068 37.08
gerade einmal 19MB.
MfG
--
Markus Schulz
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Ingo Bruell
Oct 19, 2012, 5:30:02 PM10/19/12
to
Hallo Markus,
habe ich das richtig gesehen, dass du der JVM 12 GB Speicher zuteilst ?
Ich kann mir vorstellen, das der GarbageCollector, falls nötig eine
verhältnismässig lange Zeit benötigt, um den gesamten Speicher nach
nicht referenzierten Objekten abzusuchen.
Ich habe bisher noch keinen JBoss oder einen anderen JEE Server mit mehr
als 2GB Speicher starten müssen.
Welches JDK Version wird dafür benutzt ?
habe ich das richtig gesehen, dass du der JVM 12 GB Speicher zuteilst ?
Ich kann mir vorstellen, das der GarbageCollector, falls nötig eine
verhältnismässig lange Zeit benötigt, um den gesamten Speicher nach
nicht referenzierten Objekten abzusuchen.
Ich habe bisher noch keinen JBoss oder einen anderen JEE Server mit mehr
als 2GB Speicher starten müssen.
Welches JDK Version wird dafür benutzt ?
Dirk Finkeldey
Oct 20, 2012, 2:20:02 PM10/20/12
to
Am 18.10.2012 13:18, schrieb Markus Schulz:
> Am Donnerstag, 18. Oktober 2012 schrieb Dirk Finkeldey:
>> Hm, ich habe ja nicht so viel Ahnung aber das einzige was laut deiner
>> Auflistung Last Verursacht ist Java.
>>
>> 03:35:02 PM all 5.50 0.00 1.17 68.50 0.00
>> 24.83 03:45:01 PM all 14.77 0.00 2.10
>> 31.77 0.00 51.37
>
> Dort ist aber nur IO-Last zu sehen und die kommt _nicht_ vom JBoss.
> User-Prozess-Last ist nur bei 5.5%.
> Der JBoss treibt dann nur das Load in die Höhe da die Anfragen von Nutzern ja nicht
> fertig werden und diese dann natürlich immer wieder klicken....
>
>> Zu diesen 2 Zeilen hätte ich gerne mal die atop Auflistung gesehen,
>> es scheint so als ob da jboss oder eine Komponente mächtig am System
>> zehrt.
> Die habe ich bisher noch nicht.
>
> Und ich suche immer noch nach einer Erklärung
>
> 02:05:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
> 03:35:02 PM 2674.15 591.19 1765.48 0.27 2204.80 604.31 25.38 611.91 97.18
>
> woher dieser große pgpgin/s Wert kommt bei einer Swap-Nutzung von:
>
> 02:05:01 PM kbswpfree kbswpused %swpused kbswpcad %swpcad
> 03:25:01 PM 2928824 19064 0.65 7068 37.08
>
> gerade einmal 19MB.
>
>
> MfG
Hast du automatische Backups eingerichtet ?
> Am Donnerstag, 18. Oktober 2012 schrieb Dirk Finkeldey:
>> Hm, ich habe ja nicht so viel Ahnung aber das einzige was laut deiner
>> Auflistung Last Verursacht ist Java.
>>
>> 03:35:02 PM all 5.50 0.00 1.17 68.50 0.00
>> 24.83 03:45:01 PM all 14.77 0.00 2.10
>> 31.77 0.00 51.37
>
> Dort ist aber nur IO-Last zu sehen und die kommt _nicht_ vom JBoss.
> User-Prozess-Last ist nur bei 5.5%.
> Der JBoss treibt dann nur das Load in die Höhe da die Anfragen von Nutzern ja nicht
> fertig werden und diese dann natürlich immer wieder klicken....
>
>> Zu diesen 2 Zeilen hätte ich gerne mal die atop Auflistung gesehen,
>> es scheint so als ob da jboss oder eine Komponente mächtig am System
>> zehrt.
> Die habe ich bisher noch nicht.
>
> Und ich suche immer noch nach einer Erklärung
>
> 02:05:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
> 03:35:02 PM 2674.15 591.19 1765.48 0.27 2204.80 604.31 25.38 611.91 97.18
>
> woher dieser große pgpgin/s Wert kommt bei einer Swap-Nutzung von:
>
> 02:05:01 PM kbswpfree kbswpused %swpused kbswpcad %swpcad
> 03:25:01 PM 2928824 19064 0.65 7068 37.08
>
> gerade einmal 19MB.
>
>
> MfG
Die Uhrzeit könnte zu automatisierten Backups passen.
Mit swap hat das nichts zu tun - Das System swapt ja nur wenn realer
Speicher ausgeht.
Es könnte auch durch sync. Prozesse verursacht werden.
Gruß Dirk Finkeldey
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Markus Schulz
Oct 21, 2012, 3:00:02 AM10/21/12
to
Am Freitag, 19. Oktober 2012, 23:16:39 schrieb Ingo Bruell:
> Hallo Markus,
>
> habe ich das richtig gesehen, dass du der JVM 12 GB Speicher zuteilst ?
> Ich kann mir vorstellen, das der GarbageCollector, falls nötig eine
> verhältnismässig lange Zeit benötigt, um den gesamten Speicher nach
> nicht referenzierten Objekten abzusuchen.
nein, der Speicherverbrauch der jvm (eden,survivor und oldgen) wird seperat
> Hallo Markus,
>
> habe ich das richtig gesehen, dass du der JVM 12 GB Speicher zuteilst ?
> Ich kann mir vorstellen, das der GarbageCollector, falls nötig eine
> verhältnismässig lange Zeit benötigt, um den gesamten Speicher nach
> nicht referenzierten Objekten abzusuchen.
überwacht (munin) und zeigt keine Probleme. Wenn der GarbageCollector das
Problem wäre, würde eine CPU mit Volllast laufen (dieses Problem hatten wir
bereits mehrfach)
> Ich habe bisher noch keinen JBoss oder einen anderen JEE Server mit mehr
> als 2GB Speicher starten müssen.
schon recht Speicherhungrig pro Nutzersession.
> Welches JDK Version wird dafür benutzt ?
MfG
msc
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Markus Schulz
Oct 21, 2012, 3:10:02 AM10/21/12
to
Am Samstag, 20. Oktober 2012, 20:11:07 schrieb Dirk Finkeldey:
> Am 18.10.2012 13:18, schrieb Markus Schulz:
...
> Am 18.10.2012 13:18, schrieb Markus Schulz:
> > Und ich suche immer noch nach einer Erklärung
> >
> > 02:05:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s
> > pgscand/s pgsteal/s %vmeff 03:35:02 PM 2674.15 591.19 1765.48
> > 0.27 2204.80 604.31 25.38 611.91 97.18
> >
> > woher dieser große pgpgin/s Wert kommt bei einer Swap-Nutzung von:
> >
> > 02:05:01 PM kbswpfree kbswpused %swpused kbswpcad %swpcad
> > 03:25:01 PM 2928824 19064 0.65 7068 37.08
> >
> > gerade einmal 19MB.
> >
> >
> > MfG
>
> Hast du automatische Backups eingerichtet ?
ja, bacula
> >
> > 02:05:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s
> > pgscand/s pgsteal/s %vmeff 03:35:02 PM 2674.15 591.19 1765.48
> > 0.27 2204.80 604.31 25.38 611.91 97.18
> >
> > woher dieser große pgpgin/s Wert kommt bei einer Swap-Nutzung von:
> >
> > 02:05:01 PM kbswpfree kbswpused %swpused kbswpcad %swpcad
> > 03:25:01 PM 2928824 19064 0.65 7068 37.08
> >
> > gerade einmal 19MB.
> >
> >
> > MfG
>
> Hast du automatische Backups eingerichtet ?
> Die Uhrzeit könnte zu automatisierten Backups passen.
> Mit swap hat das nichts zu tun - Das System swapt ja nur wenn realer
> Speicher ausgeht.
Total number of kilobytes the system paged in from disk
per second. Note: With old kernels (2.2.x) this value is a number of blocks
per second (and not kilobytes).
Das klinkt für mich nach Swap.
> Es könnte auch durch sync. Prozesse verursacht werden.
>
> Gruß Dirk Finkeldey
MfG
msc
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Martin Steigerwald
Oct 21, 2012, 8:40:02 AM10/21/12
to
Am Mittwoch, 17. Oktober 2012 schrieb Markus Schulz:
> Nabend,
[…]
> Nabend,
>
> Am Mittwoch, 17. Oktober 2012, 19:56:41 schrieb Martin Steigerwald:
> > Das ist ziemlich schlecht zu lesen. Ja, KMailhats jetzt nochmal
> > umgebrochen, ist aber für meine Antwort egal.
> >
> > Ich bitte Dich, diese Angaben ohne Zeilenumbruch zu senden.
>
> hab sie einfach mal als text-attachment angehangen.
> Roundcube konnte die format=flowed Mail problemlos darstellen.
> KMail nutze ich seit dem akonadi Wahnsinn kaum noch ;)
KMail aus Debian nutzt Akonadi derzeit noch gar nicht. Das einzige, was
im Standard-Setup auf Akonadi aufsetzt, ist das Adreßbuch. Den Kalender
habe ich aber auch umgestellt.
> > Zusätzlich fehlen eine ganze Reihe Angaben zum System selbst. Wie z.B. wo
> > es die Daten speichert, Hauptspeichermenge, CPU usw. Ja teilweise läßt
> > sich das aus den Sysstat-Daten rauslesen. Ich bitte dich aber, das ganze
> > etwas netter aufzubereiten, wenn du hier schon um kostenlosen Support für
> > einen Unternehmens-Server bittest.
>
> - 8x Intel(R) Xeon(R) CPU X5365 @ 3.00GHz"
> - 16GB Ram
> - 10k 72GB Disks im HW-Raid1 (hier müsste ich den Admin fragen, bin eigentlich
> nur für die Software im JBoss zuständig)
> > Auch fehlt ein Blick auf die Prozesse.
>
> auf der Kiste läuft sonst nix relevantes: ssh/ntpd/nagios-statd/nfs-
> client/bacula-fd. Alles keine Speicherfresser....
> mal aktuelle Daten um eine Vorstellung zu bekommen:
> # ps -eo cputime,etime,pmem,rss,sz,vsz,comm | grep -v "^00:00"
> TIME ELAPSED %MEM RSS SZ VSZ COMMAND
> 00:01:47 108-11:24:18 0.0 0 0 0 events/7
> 00:09:27 108-11:24:18 0.0 0 0 0 kswapd0
> 01:52:20 108-11:24:06 0.0 0 0 0 kjournald
> 00:01:07 108-11:24:05 0.0 0 0 0 edac-poller
> 00:06:01 108-11:24:03 0.0 0 0 0 flush-8:0
> 00:03:19 108-11:22:39 0.0 0 0 0 bond0
> 00:01:00 108-11:22:37 0.0 6092 8391 33564 nagios-statd
> 00:03:08 108-11:22:37 0.0 1024 8533 34132 ntpd
> 00:49:26 108-11:22:36 0.0 3384 38131 152524 bacula-fd
> 00:01:17 36-04:50:10 0.0 1116 29929 119716 rsyslogd
> 00:01:17 23-04:35:53 0.0 7236 11091 44364 munin-node
> 01:29:56 07:08:49 65.2 10747944 4430036 17720144 java
wissen, welche Prozesse zu den Zeiten mit der Page In/Out-Aktivität aktiv
sind.
Die Information wird Dir ps nicht auf die Weise liefern können wie atop.
> Der gesamte Speicher ist für den JBoss, der deshalb auch mit reservierten
> 12,5GB Heap und 512MB PermGen gestartet wird.
>
> iotop und co. wurde bereits herangezogen. der jboss erzeugt keine große io-
> Last (die lokale Platte enthält quasi keine Laufzeitdaten die cache-relevant
> sind).
> Man sieht nur kernel-threads mit hoher io-Last. (falls es ohne Swap nochmal
> auftritt protokolliere ich das)
Welche Kernel Threads sind das?
Diese Informationen sind wichtig.
> > Für einen recht netten Überblick empfehle ich atop zu verwenden. Das kann
> > I/O nach Prozess anzeigen.
> >
> > Interessanterweise gleich dann, wenn das Problem auftritt.
> > Laut
> >
> > > 14:05:01 kbmemfree kbmemused %memused
> > > kbbuffers kbcached kbcommit %commit
> > > 14:15:01 107832 16363460 99,35 162796 809300 14976404
> > >
> > > 77,12
> > ist die Speicherauslastung ziemlich hoch, wenn ich mich da nicht in den
> > Spalten vertan hab. Und das, was für Caches bereit steht, ziemlich
> > niedrig.
> >
> > Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde ich
> > auch nicht ausschalten.
>
> 800MB cache und 160MB buffers-cache sind in meinen Augen für die Kiste
> eigentlich ausreichend. Wie gesagt da liegen keine relevanten Daten auf der
> Platte die der JBoss braucht, die holt er aus dem Alfresco bzw. Postgresql.
> Der Rechner hat auch in der restlichen Zeit keine nennenswerte IO-Last.
Ich würde eine Kiste so nicht laufen lassen.
Wenn das System bei 16 GB RAM nur noch 800 MB für Caches aufbringen kann,
wird es mit hoher wahrscheinlich mit zunehmender Betriebsdauer und
Speicherfragmentierung immer intensiver nach freien Pages suchen. Meiner
groben Erinnerung nach kann das mitunter auch als Last vom Kernel-Thread
kswapd auftauchen. Die Details stehen in meinem Schulungsfolien zum
Performance Tuning Kurs nach. Aber da schaue ich heute nicht rein.
Meine Empfehlung ist: Doppelt so viel RAM rein wie der Workload erfordert.
Oder wenigstens eineinhalb mal so viel. Das dürfte bei sehr viel RAM dann
auch reichen. Auf jeden Fall: Deutlich Spielraum für Caching lassen.
Aus meinem Bauchgefühl heraus folgende Empfehlungen:
- 2.6.32 => 3.2 Backport-Kernel und schauen, was passiert. Meiner groben
Erinnerung nach hat 3.2 bereits die Anti Fragmentation Patches integriert.
- 16 GB RAM dazu stecken und schauen, was passiert.
- oder: JVM von 12 auf maximal 8 GB reduzieren und schauen, was passiert.
Meines Erachtens dürfte angesichts der Kosten für Deine Arbeitszeit und
die etwaigen Kosten für einen Dienstleister, der sich das Problem anschaut,
die einfachste *und* kostengünstigste Möglichkeit sein, der Kiste noch
16 oder 32 GB zusätzliches RAM zu verpassen.
Mich würde doch arg wundern, wenn das von Dir beschriebende Problem
dann immer noch auftritt.
Wenn das alles nicht tut, dann würde ich Dir empfehlen, Dich nach einem
Dienstleister mit Spezialisierung im Linux Performance Tuning umzuschauen,
oder aber Dich näher mit atop zu befassen.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/201210211429...@lichtvoll.de
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Markus Schulz
Oct 21, 2012, 12:40:03 PM10/21/12
to
Am Sonntag, 21. Oktober 2012, 14:29:56 schrieb Martin Steigerwald:
> Am Mittwoch, 17. Oktober 2012 schrieb Markus Schulz:
> > Nabend,
>
> […]
>
> > Nabend,
> >
> > Am Mittwoch, 17. Oktober 2012, 19:56:41 schrieb Martin Steigerwald:
> > > Das ist ziemlich schlecht zu lesen. Ja, KMailhats jetzt nochmal
> > > umgebrochen, ist aber für meine Antwort egal.
> > >
> > > Ich bitte Dich, diese Angaben ohne Zeilenumbruch zu senden.
> >
> > hab sie einfach mal als text-attachment angehangen.
> > Roundcube konnte die format=flowed Mail problemlos darstellen.
> > KMail nutze ich seit dem akonadi Wahnsinn kaum noch ;)
>
> Einfach mal so daher geschrieben, was?
Warum sollte ich, ich habe bereits viel Erfahrung mit und ohne akonadi in
> Am Mittwoch, 17. Oktober 2012 schrieb Markus Schulz:
> > Nabend,
>
> […]
>
> > Nabend,
> >
> > Am Mittwoch, 17. Oktober 2012, 19:56:41 schrieb Martin Steigerwald:
> > > Das ist ziemlich schlecht zu lesen. Ja, KMailhats jetzt nochmal
> > > umgebrochen, ist aber für meine Antwort egal.
> > >
> > > Ich bitte Dich, diese Angaben ohne Zeilenumbruch zu senden.
> >
> > hab sie einfach mal als text-attachment angehangen.
> > Roundcube konnte die format=flowed Mail problemlos darstellen.
> > KMail nutze ich seit dem akonadi Wahnsinn kaum noch ;)
>
> Einfach mal so daher geschrieben, was?
kmail/kontact gemacht (http://wordpress.tastatur-junkie.de/?p=362 , auf das
Datum des Postings achten)
> KMail aus Debian nutzt Akonadi derzeit noch gar nicht. Das einzige, was
> im Standard-Setup auf Akonadi aufsetzt, ist das Adreßbuch. Den Kalender
> habe ich aber auch umgestellt.
selbst kmail fror beim Schreiben von Mails ohne akonadi ein.
Achja, richtig, es ist ganz toll ein Adressbuch zu besitzen ohne das in kmail
nutzen zu können. Ich habe übrigens kontact/kmail bereits lange vor akondai
benutzt und war daher meine Adressbücher (imap, ldap) in kmail gewohnt.
>
> > > Zusätzlich fehlen eine ganze Reihe Angaben zum System selbst. Wie z.B.
> > > wo es die Daten speichert, Hauptspeichermenge, CPU usw. Ja teilweise
> > > läßt sich das aus den Sysstat-Daten rauslesen. Ich bitte dich aber,
> > > das ganze etwas netter aufzubereiten, wenn du hier schon um
> > > kostenlosen Support für einen Unternehmens-Server bittest.
> >
> > - 8x Intel(R) Xeon(R) CPU X5365 @ 3.00GHz"
> > - 16GB Ram
> > - 10k 72GB Disks im HW-Raid1 (hier müsste ich den Admin fragen, bin
> > eigentlich nur für die Software im JBoss zuständig)
>
> Naja, das ist schon ordentlich, bis auf das RAM.
besitzen? Für diese JEE5 Anwendung(en) ist die RAM-Menge momentan ausreichend
(die Anwendung wird von uns selbst entwickelt) und der JVM Speicherverbrauch
wird separat überwacht.
> > > Auch fehlt ein Blick auf die Prozesse.
> >
> > auf der Kiste läuft sonst nix relevantes: ssh/ntpd/nagios-statd/nfs-
> > client/bacula-fd. Alles keine Speicherfresser....
> > mal aktuelle Daten um eine Vorstellung zu bekommen:
> > # ps -eo cputime,etime,pmem,rss,sz,vsz,comm | grep -v "^00:00"
> >
> > TIME ELAPSED %MEM RSS SZ VSZ COMMAND
> >
> > 00:01:47 108-11:24:18 0.0 0 0 0 events/7
> > 00:09:27 108-11:24:18 0.0 0 0 0 kswapd0
> > 01:52:20 108-11:24:06 0.0 0 0 0 kjournald
> > 00:01:07 108-11:24:05 0.0 0 0 0 edac-poller
> > 00:06:01 108-11:24:03 0.0 0 0 0 flush-8:0
> > 00:03:19 108-11:22:39 0.0 0 0 0 bond0
> > 00:01:00 108-11:22:37 0.0 6092 8391 33564 nagios-statd
> > 00:03:08 108-11:22:37 0.0 1024 8533 34132 ntpd
> > 00:49:26 108-11:22:36 0.0 3384 38131 152524 bacula-fd
> > 00:01:17 36-04:50:10 0.0 1116 29929 119716 rsyslogd
> > 00:01:17 23-04:35:53 0.0 7236 11091 44364 munin-node
> > 01:29:56 07:08:49 65.2 10747944 4430036 17720144 java
>
> Das meinte ich anders: Ich habe atop nicht umsonst erwähnt. Ich möchte
> wissen, welche Prozesse zu den Zeiten mit der Page In/Out-Aktivität aktiv
> sind.
>
> Die Information wird Dir ps nicht auf die Weise liefern können wie atop.
halt kernel threads (kswapd iirc) und jboss-threads zu sehen.
> > Der gesamte Speicher ist für den JBoss, der deshalb auch mit reservierten
> > 12,5GB Heap und 512MB PermGen gestartet wird.
> >
> > iotop und co. wurde bereits herangezogen. der jboss erzeugt keine große
> > io- Last (die lokale Platte enthält quasi keine Laufzeitdaten die
> > cache-relevant sind).
> > Man sieht nur kernel-threads mit hoher io-Last. (falls es ohne Swap
> > nochmal auftritt protokolliere ich das)
>
> Aha.
>
> Welche Kernel Threads sind das?
>
> Diese Informationen sind wichtig.
protokolliert (dann auch mit atop).
> > > Mich wundert das nicht, dass die Kiste lahm ist. Und das Swap würde ich
> > > auch nicht ausschalten.
> >
> > 800MB cache und 160MB buffers-cache sind in meinen Augen für die Kiste
> > eigentlich ausreichend. Wie gesagt da liegen keine relevanten Daten auf
> > der Platte die der JBoss braucht, die holt er aus dem Alfresco bzw.
> > Postgresql. Der Rechner hat auch in der restlichen Zeit keine
> > nennenswerte IO-Last.
>
> 16 GB RAM mit 800 MB frei für Caches? Da klingeln bei mir die Alarmglocken.
> Ich würde eine Kiste so nicht laufen lassen.
>
> Wenn das System bei 16 GB RAM nur noch 800 MB für Caches aufbringen kann,
> wird es mit hoher wahrscheinlich mit zunehmender Betriebsdauer und
> Speicherfragmentierung immer intensiver nach freien Pages suchen. Meiner
> groben Erinnerung nach kann das mitunter auch als Last vom Kernel-Thread
> kswapd auftauchen. Die Details stehen in meinem Schulungsfolien zum
> Performance Tuning Kurs nach. Aber da schaue ich heute nicht rein.
>
> Meine Empfehlung ist: Doppelt so viel RAM rein wie der Workload erfordert.
> Oder wenigstens eineinhalb mal so viel. Das dürfte bei sehr viel RAM dann
> auch reichen. Auf jeden Fall: Deutlich Spielraum für Caching lassen.
größten Brocken direkt zugewiesen (-Xms == -Xmx, da die jvm ihren Speicher
selbst verwaltet. Das Betriebssystem hat dann eigentlich mit der
Speicherverwaltung nicht mehr so viel zu tun, die ~13GB an java sind halt
dauerhaft vergeben.
Ich formuliere meine Frage jetzt um:
was bedeutet exakt pgpgin/s? und wie kann ich ohne Swap noch pages von disk
lesen?
MfG
msc
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Martin Steigerwald
Oct 21, 2012, 3:30:01 PM10/21/12
to
weise lösen, als ich für sinnvoll erachte.
Wie Java den Speicher verwaltet, damit kenne ich mich nicht sonderlich
gut aus.
Und meine Empfehlung, die ich hier in diesem Rahmen noch zu geben
bereit ja, hast Du auch.
Daher klinke ich mich hier aus.
Zu der Bedeutung:
pgpgin/s
Total number of kilobytes the system paged in from disk per second.
Stichwort: Page faults, eine Page ist nicht im Speicher und die
virtuelle Speicherverwaltung lädt sie ein.
merkaba:~> echo 3 > /proc/sys/vm/drop_caches | /usr/bin/time -v perl
Command being timed: "perl"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.79
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1812
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 3
Minor (reclaiming a frame) page faults: 520
Voluntary context switches: 13
Involuntary context switches: 3
Swaps: 0
File system inputs: 3488
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
Hier als Major Page Fault.
Einige Fälle dafür:
- Teile von ausführbaren Programmen oder Bibliotheken laden.
- Via mmap() in den Speicher eingeblendete Dateien
- Ich glaub da war noch was, fällt mir aber grade nicht ein.
Abgesehen davon habe ich noch grob in Erinnerung, dass auch eine PostgreSQL
auf dem System läuft. Die braucht auch RAM.
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/201210212126...@lichtvoll.de
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Dirk Finkeldey
Oct 21, 2012, 8:00:01 PM10/21/12
to
Am 21.10.2012 09:01, schrieb Markus Schulz:
> Am Samstag, 20. Oktober 2012, 20:11:07 schrieb Dirk Finkeldey:
>> Am 18.10.2012 13:18, schrieb Markus Schulz:
> ...
>>> Und ich suche immer noch nach einer Erklärung
>>>
>>> 02:05:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s
>>> pgscand/s pgsteal/s %vmeff 03:35:02 PM 2674.15 591.19 1765.48
>>> 0.27 2204.80 604.31 25.38 611.91 97.18
>>>
>>> woher dieser große pgpgin/s Wert kommt bei einer Swap-Nutzung von:
>>>
>>> 02:05:01 PM kbswpfree kbswpused %swpused kbswpcad %swpcad
>>> 03:25:01 PM 2928824 19064 0.65 7068 37.08
>>>
>>> gerade einmal 19MB.
>>>
>>>
>>> MfG
>> Hast du automatische Backups eingerichtet ?
> ja, bacula
>
>> Die Uhrzeit könnte zu automatisierten Backups passen.
> um 15:30Uhr nachmittags fahren wir keine Backups...
Was laufen dann für Aktivitäten auf den System & was sind da noch für
> Am Samstag, 20. Oktober 2012, 20:11:07 schrieb Dirk Finkeldey:
>> Am 18.10.2012 13:18, schrieb Markus Schulz:
> ...
>>> Und ich suche immer noch nach einer Erklärung
>>>
>>> 02:05:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s
>>> pgscand/s pgsteal/s %vmeff 03:35:02 PM 2674.15 591.19 1765.48
>>> 0.27 2204.80 604.31 25.38 611.91 97.18
>>>
>>> woher dieser große pgpgin/s Wert kommt bei einer Swap-Nutzung von:
>>>
>>> 02:05:01 PM kbswpfree kbswpused %swpused kbswpcad %swpcad
>>> 03:25:01 PM 2928824 19064 0.65 7068 37.08
>>>
>>> gerade einmal 19MB.
>>>
>>>
>>> MfG
>> Hast du automatische Backups eingerichtet ?
> ja, bacula
>
>> Die Uhrzeit könnte zu automatisierten Backups passen.
> um 15:30Uhr nachmittags fahren wir keine Backups...
Prozesse involviert ?
>
>> Mit swap hat das nichts zu tun - Das System swapt ja nur wenn realer
>> Speicher ausgeht.
> pgpgin/s
> Total number of kilobytes the system paged in from disk
> per second. Note: With old kernels (2.2.x) this value is a number of blocks
> per second (and not kilobytes).
>
> Das klinkt für mich nach Swap.
Nein da wird irgendwas von der Festplatte gelesen bzw nach geladen -
>> Mit swap hat das nichts zu tun - Das System swapt ja nur wenn realer
>> Speicher ausgeht.
> pgpgin/s
> Total number of kilobytes the system paged in from disk
> per second. Note: With old kernels (2.2.x) this value is a number of blocks
> per second (and not kilobytes).
>
> Das klinkt für mich nach Swap.
könnte von jeder Art Datenanforderung sein .
>> Es könnte auch durch sync. Prozesse verursacht werden.
> Was sind sync.Prozesse?
Syncronisation zb von Datenbanken.
> Was sind sync.Prozesse?
>> Gruß Dirk Finkeldey
>
> MfG
> msc
Gruß Dirk Finkeldey
>
> MfG
> msc
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Ingo Brüll
Oct 22, 2012, 8:10:01 AM10/22/12
to
Hi Markus,
> > habe ich das richtig gesehen, dass du der JVM 12 GB Speicher
> > zuteilst ? Ich kann mir vorstellen, das der GarbageCollector, falls
> > nötig eine verhältnismässig lange Zeit benötigt, um den gesamten
> > Speicher nach nicht referenzierten Objekten abzusuchen.
>
> nein, der Speicherverbrauch der jvm (eden,survivor und oldgen) wird
> seperat überwacht (munin) und zeigt keine Probleme. Wenn der
> GarbageCollector das Problem wäre, würde eine CPU mit Volllast laufen
> (dieses Problem hatten wir bereits mehrfach)
>
> > Ich habe bisher noch keinen JBoss oder einen anderen JEE Server mit
> > mehr als 2GB Speicher starten müssen.
>
> naja auf dem Rechner läuft ein Portal und die Anwendungen (portlets)
> sind schon recht Speicherhungrig pro Nutzersession.
>
> > Welches JDK Version wird dafür benutzt ?
>
> sun-jdk-6.26
Da hätte ich als Idee den neuen GC1, der in der Version schon enthalten
sein soll. Aber wenn es nicht der GC ist, wird das nicht viel bringen.
Grüße
Ingo
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/20121022140...@ibruell-desktop.intern-enexoma.de
> > habe ich das richtig gesehen, dass du der JVM 12 GB Speicher
> > zuteilst ? Ich kann mir vorstellen, das der GarbageCollector, falls
> > nötig eine verhältnismässig lange Zeit benötigt, um den gesamten
> > Speicher nach nicht referenzierten Objekten abzusuchen.
>
> nein, der Speicherverbrauch der jvm (eden,survivor und oldgen) wird
> seperat überwacht (munin) und zeigt keine Probleme. Wenn der
> GarbageCollector das Problem wäre, würde eine CPU mit Volllast laufen
> (dieses Problem hatten wir bereits mehrfach)
>
> > Ich habe bisher noch keinen JBoss oder einen anderen JEE Server mit
> > mehr als 2GB Speicher starten müssen.
>
> naja auf dem Rechner läuft ein Portal und die Anwendungen (portlets)
> sind schon recht Speicherhungrig pro Nutzersession.
>
> > Welches JDK Version wird dafür benutzt ?
>
> sun-jdk-6.26
sein soll. Aber wenn es nicht der GC ist, wird das nicht viel bringen.
Grüße
Ingo
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Markus Schulz
Oct 25, 2012, 3:20:02 PM10/25/12
to
Nabend,
Am Mittwoch, 17. Oktober 2012, 18:59:11 schrieb Markus Schulz:
> Moin,
>
> wir haben in der Firma einen Debian/Squeeze Rechner der von Zeit zu
> Zeit sehr hohes IOWait erzeugt und anschließend dann durch den darauf
> laufenden JBoss EAP5 auch ein sehr hohes Load. Daraus resultiert dann
> eine extrem schlechte Performance der EAP-Anwendung.
Um das Thema noch abzuschließen:
Es hat sich heraus gestellt(atop/iotop), das die IO-Last doch durch den JBoss
ausgelöst wird. Es läuft ein Wartungs-Job (im Zyklus des ejb3-sfsb
removalTimeoutSeconds) der bei unserer Konfiguration alle n * 24h durchlaufen
wird. Dieser soll passivierte SFSB entsorgen (dort können schonmal > 1 mio
passivierte beans liegen).
Dabei entsteht diese hohe Last.
Das Problem wird jetzt mit dem Support von redhat weiter diskutiert.
Als Workaround wurden erstmal zwei Samsung SSDs eingebaut und das Filesystem
von ext3 auf ext4 aktualisiert, damit wird diese Last problemlos abgefangen
und stört erstmal den Produktivbetrieb nicht mehr.
Danke an alle Helfer.
MfG
msc
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Archive: http://lists.debian.org/20121025211...@antzsystem.de
Am Mittwoch, 17. Oktober 2012, 18:59:11 schrieb Markus Schulz:
> Moin,
>
> wir haben in der Firma einen Debian/Squeeze Rechner der von Zeit zu
> Zeit sehr hohes IOWait erzeugt und anschließend dann durch den darauf
> laufenden JBoss EAP5 auch ein sehr hohes Load. Daraus resultiert dann
> eine extrem schlechte Performance der EAP-Anwendung.
Es hat sich heraus gestellt(atop/iotop), das die IO-Last doch durch den JBoss
ausgelöst wird. Es läuft ein Wartungs-Job (im Zyklus des ejb3-sfsb
removalTimeoutSeconds) der bei unserer Konfiguration alle n * 24h durchlaufen
wird. Dieser soll passivierte SFSB entsorgen (dort können schonmal > 1 mio
passivierte beans liegen).
Dabei entsteht diese hohe Last.
Das Problem wird jetzt mit dem Support von redhat weiter diskutiert.
Als Workaround wurden erstmal zwei Samsung SSDs eingebaut und das Filesystem
von ext3 auf ext4 aktualisiert, damit wird diese Last problemlos abgefangen
und stört erstmal den Produktivbetrieb nicht mehr.
Danke an alle Helfer.
MfG
msc
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
Dirk Finkeldey
Oct 25, 2012, 7:40:01 PM10/25/12
to
Am 25.10.2012 21:14, schrieb Markus Schulz:
> Nabend,
>
> Am Mittwoch, 17. Oktober 2012, 18:59:11 schrieb Markus Schulz:
>> Moin,
>>
>> wir haben in der Firma einen Debian/Squeeze Rechner der von Zeit zu
>> Zeit sehr hohes IOWait erzeugt und anschließend dann durch den darauf
>> laufenden JBoss EAP5 auch ein sehr hohes Load. Daraus resultiert dann
>> eine extrem schlechte Performance der EAP-Anwendung.
> Um das Thema noch abzuschließen:
> Es hat sich heraus gestellt(atop/iotop), das die IO-Last doch durch den JBoss
> ausgelöst wird. Es läuft ein Wartungs-Job (im Zyklus des ejb3-sfsb
> removalTimeoutSeconds) der bei unserer Konfiguration alle n * 24h durchlaufen
> wird. Dieser soll passivierte SFSB entsorgen (dort können schonmal > 1 mio
> passivierte beans liegen).
> Dabei entsteht diese hohe Last.
> Das Problem wird jetzt mit dem Support von redhat weiter diskutiert.
> Als Workaround wurden erstmal zwei Samsung SSDs eingebaut und das Filesystem
> von ext3 auf ext4 aktualisiert, damit wird diese Last problemlos abgefangen
> und stört erstmal den Produktivbetrieb nicht mehr.
>
> Danke an alle Helfer.
>
> MfG
> msc
Wuste ich es doch Java ;-)
> Nabend,
>
> Am Mittwoch, 17. Oktober 2012, 18:59:11 schrieb Markus Schulz:
>> Moin,
>>
>> wir haben in der Firma einen Debian/Squeeze Rechner der von Zeit zu
>> Zeit sehr hohes IOWait erzeugt und anschließend dann durch den darauf
>> laufenden JBoss EAP5 auch ein sehr hohes Load. Daraus resultiert dann
>> eine extrem schlechte Performance der EAP-Anwendung.
> Um das Thema noch abzuschließen:
> Es hat sich heraus gestellt(atop/iotop), das die IO-Last doch durch den JBoss
> ausgelöst wird. Es läuft ein Wartungs-Job (im Zyklus des ejb3-sfsb
> removalTimeoutSeconds) der bei unserer Konfiguration alle n * 24h durchlaufen
> wird. Dieser soll passivierte SFSB entsorgen (dort können schonmal > 1 mio
> passivierte beans liegen).
> Dabei entsteht diese hohe Last.
> Das Problem wird jetzt mit dem Support von redhat weiter diskutiert.
> Als Workaround wurden erstmal zwei Samsung SSDs eingebaut und das Filesystem
> von ext3 auf ext4 aktualisiert, damit wird diese Last problemlos abgefangen
> und stört erstmal den Produktivbetrieb nicht mehr.
>
> Danke an alle Helfer.
>
> MfG
> msc
Gruß Dirk Finkeldey
--
Zum AUSTRAGEN schicken Sie eine Mail an debian-user-g...@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listm...@lists.debian.org (engl)
0 new messages