System Ressourcen erreichen den schwarzen Bereich - numfile!

R

Rene

New Member
Hallo,

ich habe eine nette Kiste bei HE. (Virtual Server Linux MAX 3.0).
Nach einer durchgängigen Laufzeit von 1 ~ 2 Wochen fährt sich der VServer an die Wand, da die System Ressourcen erst den gelben und dann den schwarzen Bereich erreichen - hier hilft dann nur noch ein neustart.
Das Ganze ist bedingt durch numfile - erreicht nämlich sein hardlimit.

Gerade sind die ressourcen im gelben Bereich, darum einmal ein "cat /proc/user_beancounters"

Code: 
uid  resource       held     maxheld     barrier      limit       failcnt
3826:kmemsize       27806272   27824272   42170777   46387854          0
    lockedpages           0          0       2059       2059       1356
    privvmpages      491859     491900    1310720    1331200          0
    shmpages           5955       5955      50000      50000          0
    dummy                 0          0          0          0          0
    numproc             809        809       1028       1028          0
    physpages        170424     170425          0 2147483647          0
    vmguarpages           0          0     524288 2147483647          0
    oomguarpages     172340     172341     524288 2147483647          0
    numtcpsock          114        114       1028       1028          0
    numflock             10         10       1000       1100          0
    numpty                1          1        200        200          0
    numsiginfo            0          1       1024       1024          0
    tcpsndbuf        821512     821512    6584420    9402468          0
    tcprcvbuf        821200     821200    6584420    9402468          0
    othersockbuf      82680      82680    4923119    9133807          0
    dgramrcvbuf           0          0    4923119    4923119          0
    numothersock         60         60       1028       1028          0
    dcachesize            0          0    9198104    9474048          0
    [B]numfile           14918      14927      16448      16448       3720[/B]
    dummy                 0          0          0          0          0
    dummy                 0          0          0          0          0
    dummy                 0          0          0          0          0
    numiptent            16         16 2147483647 2147483647          0

Angehängt habe ich auch einen ausgiebigen lsof output.

Vllt. hat ja schon einer Erfahrungen mit Vservern von Host Europe und numfile gemacht oder kann mir generell etwas zu meinem Problemchen raten :-)

Danke!
 

Attachments

Last edited by a moderator:
Hier im Forum gibt es bereits diverse Threads zu diesem Thema. Suche mal über die "erweiterte Suche" nach dem Begriff numfiles im Titel.

Ferner sei Dir das Howto von Huschi ans Herz gelegt. Mit fundierten Aussagen bitte wieder an uns wenden :)

--marneus
 
marneus said:
Hier im Forum gibt es bereits diverse Threads zu diesem Thema. Suche mal über die "erweiterte Suche" nach dem Begriff numfiles im Titel.
Click to expand...

Ist mir bekannt. 5 an der Zahl. Nur keiner führt -ansatzweise- etwas zur Problembehebung bei.

marneus said:
Ferner sei Dir das Howto von Huschi ans Herz gelegt.
Click to expand...

Jup, kenne ich. Habe auch einen lsof Output angehängt sowie mir div. Sachen angeschaut.

marneus said:
Mit fundierten Aussagen bitte wieder an uns wenden :)
Click to expand...

Was braucht ihr denn von mir, um gemeinsam das Problem/Ursache zu erörtern?
 
Ich hab den Anhang übersehen, da wir hier sowas normalerweise in CODE-Tags packen und somit nicht der Umweg gegangen werden muss.

Das Ergebnis summiert nach Usern stellt sich wie folgt dar:
bind Anzahl 33
drweb Anzahl 28
list Anzahl 327
mysql Anzahl 137
ossec Anzahl 37
ossecm Anzahl 16
popuser Anzahl 176
psaadm Anzahl 189
qmaild Anzahl 13
qmaill Anzahl 8
qmailq Anzahl 7
qmailr Anzahl 7
qmails Anzahl 14
root Anzahl 1549
syslog Anzahl 25
tomcat Anzahl 153
www-data Anzahl 418
Gesamtanzahl 3137

Ich würde sagen, Openfire macht Dir große Probleme (454 offene Dateien) sowie der Apache (418).

--marneus
 
Last edited by a moderator:
Ja, ich fand den lsof output etwas zu lang, um ihn hier herein zu klatschen.
Habe auch schon bemerkt, dass wohl openfire zuviele Dateien öffnet, aber das dürfte eigentlich gar nicht sein. Die Leute aus dem offiziellen Openfire-Forum können sich das auch nicht erklären.

Ein ls -l /proc/18380/fd/ (für openfire pid) gibt mir total 345 aus. Laut Entwickler nichts, worüber man sich Sorgen machen sollte.
 
Sorgen musst Du Dir prinzipiell um nichts machen, nur gibt Dein Server die Ressourcen nicht her.

Du könntest evtl. den Apache ein wenig kastrieren.

--marneus
 
Mich wundert gerade, warum Tomcat in der Liste auftaucht? Ich habe sämtliche Module sowie Anwendungen deaktiviert.

Was könnte ich denn am Apache drehen?
 
Gute Frage! Wie kann ich erken, was ich benutze und es ggf. auf den Worker (soll von Hause aus performanter sein) ändern?
 
traced said:
Poste doch mal in Code-Tags die Ausgabe von "ps aux|grep apache"
Click to expand...

Code: 
root     30699  0.0  0.0  29012 12588 ?        Ss   13:54   0:00 /usr/sbin/apache2 -k start -DSSL
www-data 31745  0.0  0.1  37880 19972 ?        S    13:54   0:00 /usr/sbin/apache2 -k start -DSSL
www-data 32332  0.0  0.1  38560 20760 ?        S    13:59   0:01 /usr/sbin/apache2 -k start -DSSL
www-data 32338  0.0  0.1  37912 20024 ?        S    13:59   0:00 /usr/sbin/apache2 -k start -DSSL
www-data  9785  0.0  0.1  37976 19580 ?        S    14:25   0:00 /usr/sbin/apache2 -k start -DSSL
www-data  9788  0.0  0.1  37824 19860 ?        S    14:25   0:00 /usr/sbin/apache2 -k start -DSSL
root     19928  0.0  0.0   1552   532 pts/0    S+   14:58   0:00 grep apache

Bitte sehr.
 
Rene,
optimieren und bei den Ressourcen sparen ist selbstverständlich wichtig. Aber was mich stört, dass Dein VServer MAX 3.0 auch nur so viele numfiles in der Konfiguration spendiert bekommt, wie der kleine L 3.0
Das solltest Du bei HE mal anfragen, ob das so gewollt ist.

Gruß Fritz
 
Last edited by a moderator:
Fritz said:
Rene,
optimieren und bei den Ressourcen sparen ist selbstverständlich wichtig. Aber was mich stört, dass Dein VServer MAX 3.0 auch nur so viele numfiles in der Konfiguration spendiert bekommt, wie der kleine L 3.0
Das solltest Du bei HE mal anfragen, ob das so gewollt ist.
Click to expand...

Naja, da könnte man jetzt sagen, dass ich ein größeres Paket habe, welchem mehr Leistung zugeschrieben werden sollte, jedoch ist ein hardlimit bei den numfiles von über 16k schon richtig viel - das dürftem an so leicht eigetnlich nicht knacken können...

Gibt es noch weitere Anregungen zum meinem Problemchen?

Danke!
 
So, in Anbetracht von

Code: 
VPS Speichernutzung:
Momentan genutzt:       1839.45 MB
Maximal genutzt:        1839.45 MB
Zugesichert:            2048 MB
Maximal nutzbar:        5200 MB

habe ich mal das Script tuning-primer it folgenden Ergebnis durchlaufen lassen:

Code: 
root@www:~# tuning-primer.sh
mysqld is alive

        -- MYSQL PERFORMANCE TUNING PRIMER --
             - By: Matthew Montgomery -

MySQL Version 5.0.22-Debian_0ubuntu6.06.9-log i486

/usr/bin/tuning-primer.sh: line 389: bc: command not found
/usr/bin/tuning-primer.sh: line 390: bc: command not found
/usr/bin/tuning-primer.sh: line 391: bc: command not found
/usr/bin/tuning-primer.sh: line 392: bc: command not found
/usr/bin/tuning-primer.sh: line 393: bc: command not found
/usr/bin/tuning-primer.sh: line 394: bc: command not found
Uptime =  days  hrs  min  sec
Avg. qps = 0
Total Questions = 123978
Threads Connected = 2

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is [B]NOT[/B] enabled.
Current long_query_time = 10 sec.
You have [B]1[/B] out of [B]123992[/B] that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.

BINARY UPDATE LOG
The binary update log is enabled

WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 1
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 2
Historic max_used_connections = 7
The number of used connections is 7% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

MEMORY USAGE
/usr/bin/tuning-primer.sh: line 1205: bc: command not found
/usr/bin/tuning-primer.sh: line 1206: bc: command not found
/usr/bin/tuning-primer.sh: line 1230: bc: command not found
/usr/bin/tuning-primer.sh: line 1233: bc: command not found
/usr/bin/tuning-primer.sh: line 1234: bc: command not found
/usr/bin/tuning-primer.sh: line 1236: bc: command not found
/usr/bin/tuning-primer.sh: line 1238: [: -gt: unary operator expected
/usr/bin/tuning-primer.sh: line 351: [: max_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 357: [: max_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 363: [: max_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 370: export: `0=max_memoryHR': not a valid identifier
Max Memory Ever Allocated :  bytes
/usr/bin/tuning-primer.sh: line 351: [: per_thread_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 357: [: per_thread_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 363: [: per_thread_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 370: export: `0=per_thread_buffersHR': not a valid identifier
Configured Max Per-thread Buffers :  bytes
/usr/bin/tuning-primer.sh: line 351: [: global_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 357: [: global_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 363: [: global_buffersHR: integer expression expected
/usr/bin/tuning-primer.sh: line 370: export: `0=global_buffersHR': not a valid identifier
Configured Max Global Buffers :  bytes
/usr/bin/tuning-primer.sh: line 351: [: total_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 357: [: total_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 363: [: total_memoryHR: integer expression expected
/usr/bin/tuning-primer.sh: line 370: export: `0=total_memoryHR': not a valid identifier
Configured Max Memory Limit :  bytes
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Physical Memory :  G
Max memory limit seem to be within acceptable norms

KEY BUFFER
/usr/bin/tuning-primer.sh: line 332: bc: command not found
/usr/bin/tuning-primer.sh: line 647: bc: command not found
/usr/bin/tuning-primer.sh: line 648: bc: command not found
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current MyISAM index space =  M
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current key_buffer_size =  M
Key cache miss rate is 1 : 39
Key buffer fill ratio =  %
/usr/bin/tuning-primer.sh: line 681: [: -ge: unary operator expected
/usr/bin/tuning-primer.sh: line 685: [: -ge: unary operator expected
/usr/bin/tuning-primer.sh: line 689: [: -le: unary operator expected
Your key_buffer_size seems to be fine

QUERY CACHE
/usr/bin/tuning-primer.sh: line 720: bc: command not found
/usr/bin/tuning-primer.sh: line 721: bc: command not found
Query cache is enabled
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current query_cache_size =  M
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current query_cache_used =  M
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current query_cache_limit =  M
Current Query cache Memory fill ratio =  %
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current query_cache_min_res_unit =  K
/usr/bin/tuning-primer.sh: line 734: bc: command not found
/usr/bin/tuning-primer.sh: line 735: bc: command not found
/usr/bin/tuning-primer.sh: line 736: [: -gt: unary operator expected
/usr/bin/tuning-primer.sh: line 743: [: -le: unary operator expected
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current sort_buffer_size =  M
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current read_rnd_buffer_size =  K
Sort buffer seems to be fine

JOINS
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current join_buffer_size =  K
You have had 20 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 1024 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 64 tables
You have a total of 535 tables
You have [B]64[/B] open tables.
Current table_cache hit rate is [B]1%[/B], while [B]100%[/B] of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current max_heap_table_size =  M
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current tmp_table_size =  M
Of 8867 temp tables, 8% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
/usr/bin/tuning-primer.sh: line 332: bc: command not found
Current read_buffer_size =  K
Current table scan ratio = 67 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 33305
Your table locking seems to be fine

Ich werde die Vorschläge einmal in die Tat umsetzen und schauen, ob es besser wird.

Ferner habe ich etwas bzgl. meiner numfile Problematik in Erfahrung bringen können:

Ich habe eine längere Diskussion mit einem der Entwickler von openfire geführt und diese sind sich sicher, dass es ein Feature oder Bug in der Nutzung der Java VM Software ist (ich nutze 1.6 SDK auf meinem ubuntu 6.06). Entweder öffnet diese neue Dateien, welche nicht genutzt werden oder es schließt sie nicht richtig. Könnte man dem hier irgendwie auf die Schliche kommen bzw Abhilfe schaffen?
 
Fritz said:
apt-get install bc, und das script läuft besser.
Click to expand...

done.

Code: 
mysqld is alive

        -- MYSQL PERFORMANCE TUNING PRIMER --
             - By: Matthew Montgomery -

MySQL Version 5.0.22-Debian_0ubuntu6.06.9-log i486

Uptime = 0 days 1 hrs 41 min 0 sec
Avg. qps = 1
Total Questions = 7688
Threads Connected = 2

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is [B]NOT[/B] enabled.
Current long_query_time = 10 sec.
You have [B]0[/B] out of [B]7702[/B] that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.

BINARY UPDATE LOG
The binary update log is enabled

WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 1
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 2
Historic max_used_connections = 5
The number of used connections is 5% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

MEMORY USAGE
Max Memory Ever Allocated : 48 M
Configured Max Per-thread Buffers : 265 M
Configured Max Global Buffers : 34 M
Configured Max Memory Limit : 300 M
Physical Memory : 15.84 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 9 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 13
Key buffer fill ratio = 1.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 16 M
Current query_cache_used = 1 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 10.24 %
Current query_cache_min_res_unit = 4 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 3 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 1024 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 64 tables
You have a total of 535 tables
You have [B]64[/B] open tables.
Current table_cache hit rate is [B]1%[/B], while [B]100%[/B] of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 715 temp tables, 4% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 24 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 7822
Your table locking seems to be fine

Sehr seltsam fine ich den Passus über Slow Queries. Ich habe eben das Logging für Slow Queries aktiviert, aber das Script meint immer noch, es wird nicht geloggt. Logfile ist ebenfalls leer.

- wo finde ich eignetlich die Option "Current long_query_time = 10 sec." ?
- und bzgl. des Table Cache, soltle ich hier das Value höher stellen?
 
Hallo!
Die Einstellungen werden über die mySQL Konfigurationsdatei (my.cnf) geregelt. Nach einer Änderung den mySQL Server einmal durchstarten. Allerdings sollte der Server nach einer Änderungen erst mal 48 Stunden laufen, um aussagekräftige Werte zu erhalten.

mfG
Thorsten
 
You must log in or register to reply here.
Back
Top