Regelmäßige "Socket Failure"s auf meinem VServer von S4You

A

anselmoso

Registered User
Hallo zusammen,

ich habe den kleinsten VServer bei S4You (mit Debian 3.1) und bekomme da regelmäßig "Socket Failures". Z.B. habe ich einen Squid am Laufen und muss den sehr oft neu starten, weil er folgende Fehlermeldung (im Browser, über den ich ihn nutze) bringt:

The following error was encountered:

* Socket Failure

The system returned:

(105) No buffer space available

Squid is unable to create a TCP socket, presumably due to excessive load. Please retry your request.
Click to expand...

Die squid.conf sieht so aus:

acl all src 0.0.0.0/0.0.0.0
acl me src xxx.xxx.xxx.xxx/255.255.255.255
http_access allow me
http_reply_access allow me
http_access deny all

http_port xx

#deactivate unneeded log files
cache_access_log /dev/null
cache_store_log /dev/null
cache_log /dev/null
Click to expand...


Manchmal hilft auch, im Browser die entspr. Webseite dann zu reloaden, manchmal werden dann auch Bilder auf der Webseite einfach nicht geladen - oft muss ich den Squid aber komplett restarten. Die Anzahl der Squid Prozesse ist je nachdem wie viele Tabs ich im Browser offen habe teilweise schon hoch, also 20-30 Stück könnens schon sein.

Ebenso erhalte ich dann eine Fehlermeldung wenn ich z.B. "centerim" (=Konsolen ICQ Client) starten will, der bringt dann auch "Socket Problems" und kann sich nicht zum ICQ Server connecten. Dann muss ich einige Minuten oder länger warten und dann läuft centerim meist wieder.

Habt ihr ne Ahnung womit das zusammen hängt? Ich kann mir vorstellen, dass das mit den anderen VServern auf dem Server zusammen hängt, auf welchem mein VServer sich befindet...?


Der Server ist so gut wie gar nicht belastet, läuft noch kein Webserver drauf, der von außen genutzt wird oder dergleichen. Auch sonst sind nach außen keine Prozesse offen außer der Squid, den ja sowieso nur ich mit meiner IP nutzen kann. Aktuelle Updates sind installiert und werden per cron-apt auch regelmäßig gecheckt.
 
Last edited by a moderator:
Es könnte auch sein, dass du deinen dir zugestandenen Puffer für Verbindungen aufgebraucht hast.

Schau doch bitte mal in /proc/user_beancounters nach wie es um tcpsndbuf und tcprcvbuf steht, insbesondere den failcnt. Und damit wir auch genauer helfen können, wäre es praktisch, wenn du den Inhalt dieser Datei hier posten würdest.

Eventuell lohnt es sich auch noch, nach anderen Diensten zu suchen, die Verbindungen bereithalten / brauchen.
 
Vielen Dank erstmal für die schnelle Antwort.

/proc/user_beancounters:

Code: 
Version: 2.5
uid resource held maxheld barrier limit failcnt
185014: kmemsize 4036680 5889361 8467453 9314198 0
lockedpages 0 283 344 344 6
privvmpages 38046 100192 131072 139264 0
shmpages 1003 4859 19567 19567 0
dummy 0 0 0 0 0
numproc 48 69 96 96 0
physpages 5860 60626 0 9223372036854775807 0
vmguarpages 0 0 65536 9223372036854775807 0
oomguarpages 5862 61528 65536 9223372036854775807 0
numtcpsock 135 152 152 152 22245
numflock 5 29 224 246 0
numpty 1 3 16 16 0
numsiginfo 0 38 512 512 0
tcpsndbuf 243752 1077328 1416560 2768240 0
tcprcvbuf 278136 1568896 1416560 2768240 2467
othersockbuf 135952 426888 655717 1153621 0
dgramrcvbuf 0 8784 655717 655717 0
numothersock 89 156 198 198 0
dcachesize 0 0 1503190 1548286 0
numfile 1434 2590 3008 3008 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 10 10 48 48 0
 
Last edited by a moderator:
Code: 
tcprcvbuf 278136 1568896 1416560 2768240 [B]2467[/B]

Hier liegt Dein Problem, die letzte Zahl ist die Menge der Überschreitungen!

lg Basti

PS: Die Werte werden bei s4u sehr eng gehalten...
 
Und wie verhindere ich, dass der Wert überschritten wird?

Bedeutet dass auch, dass ich mit dem VServer einen kleinen Webserver, auf dem >100 Leute gleichzeitig surfen, vergessen kann?
 
Das ist immer so das Problem, you get what you payed for...
Ich bin von s4u zu Strato gewechselt, zahle jetzt 6 Öcken mehr, aber hab meine Ruhe, weil die Userbeancounters nicht so paranoid beschränkt wurden...

Aber es gibt immer irgendwo Optimierungsbedarf. Wie sieht denn Dein Setup aus? Betriebssystem, Webserver, Mysql? Je mehr Informationen wir bekommen, desto eher können wir Dir hier helfen.

lg Basti
 
Also lsof -i spuckt folgendes aus:

apache 3284 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache 3306 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache 3307 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache 3309 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache 3310 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache 3312 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache 3317 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache 3322 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache 3323 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache 3326 www-data 16u IPv4 26225516 TCP *:www (LISTEN)
apache-ss 5165 www-data 16u IPv4 26225517 TCP *:https (LISTEN)
apache-ss 5167 www-data 16u IPv4 26225517 TCP *:https (LISTEN)
apache-ss 5168 www-data 16u IPv4 26225517 TCP *:https (LISTEN)
apache-ss 5169 www-data 16u IPv4 26225517 TCP *:https (LISTEN)
apache-ss 5172 www-data 16u IPv4 26225517 TCP *:https (LISTEN)
squid 5426 proxy 8u IPv4 443613270 UDP *:58971
squid 5426 proxy 10u IPv4 443613821 TCP *:xy (LISTEN)
squid 5426 proxy 11u IPv4 443613822 UDP *:icpv2
portmap 24551 daemon 3u IPv4 26225547 UDP *:sunrpc
portmap 24551 daemon 4u IPv4 26223955 TCP *:sunrpc (LISTEN)
inetd 25720 root 4u IPv4 26223956 TCP *:auth (LISTEN)
mysqld 25788 mysql 3u IPv4 26223957 TCP localhost.localdomain:mysql (LISTEN)
master 25972 root 11u IPv4 26224311 TCP localhost.localdomain:smtp (LISTEN)
sshd 26004 root 3u IPv4 26225514 TCP *:ssh (LISTEN)
rpc.statd 26019 root 4u IPv4 26225711 UDP *:758
rpc.statd 26019 root 5u IPv4 26225712 UDP *:755
rpc.statd 26019 root 6u IPv4 26225515 TCP *:kpasswd (LISTEN)
apache 26070 root 16u IPv4 26225516 TCP *:www (LISTEN)
apache-ss 26104 root 16u IPv4 26225517 TCP *:https (LISTEN)
Click to expand...

Betriebssystem Debian 3.1, aktuelle Updates druff. Mysql 4.1.5 läuft (nur lokaler Zugriff), Apache 1.3, Postfix (auch nur Zugriff von localhost erlaubt), Squid.
 
Last edited by a moderator:
The total size of buffers used to temporary store the data coming from TCP network connections. These socket buffers also reside in “low memory”.

Tcprcvbuf parameter depends on number of TCP sockets (numtcpsock) and should allow for some minimal amount of socket buffer memory for each socket, as discussed in UBC consistency check:

tcprcvbuf_{lim} - tcprcvbuf_{bar} \ge 2.5KB \cdot numtcpsock \rm.

If this restriction is not satisfied, some network connections may stall, being unable to receive data, and will be terminated after a couple of minutes.

Similarly to tcpsndbuf, setting high values for tcprcvbuf parameter may, but doesn't necessarily, increase performance of network communications. Hitting tcprcvbuf limits and failed socket buffer allocations do not have strong negative effect on the applications, but just reduce performance of network communications. However, staying above the barrier of tcprcvbuf parameter for a long time is less harmless than for tcpsndbuf. Long periods of exceeding the barrier may cause termination of some connections.

Tcprcvbuf limits can't be set arbitrarily high. The total amount of tcprcvbuf consumable by all containers in the system plus the kmemsize and other socket buffers is limited by the hardware resources of the system. This total limit is discussed in “low memory”.
Click to expand...

Sagt das OpenVZ Wiki.

Was mich aber wundert, ich habe auch auf dem kleinen s4u der jetzt dann ausläuft noch einen Squid laufen, trotz anderer Dienste, und habe keinen Stress damit!?
 
Kann ich irgendwie die Squid-Prozesse begrenzen? Mein Squid macht (auch wenn ich nur eine Webseite ansurfe über den Browser) leider immer mehrere Prozesse auf pro Webseite, die ich offen habe.
 
Interessant, seit dem Strmoausfall gestern bei S4You habe ich bislang nur 1 Mal das genannte Problem gehabt, die Beancounters sehen auch besser aus:

resource held maxheld barrier limit failcnt
tcprcvbuf 196840 1047216 1416560 2768240 0
Click to expand...

Komisch....mal sehen, wie lange das so bleibt.
 
Hi,

barrier und limit haben die selben Werte wie bei Deinem alten Auszug. Das der failcnt auf 0 ist liegt an dem zwangsläufigen Reboot des Hostsystems ;)


-W
 
Ja, aber komischerweise treten die "Socket Failure" Probleme nicht mehr auf seit Reboot der Server. Mit "Hostsystem" meinst du wahrscheinlich den physischen Server, auf dem mein VServer (mit ein paar anderen) läuft?
Ein Reboot meines VServers selbst regelmäßig bringt also wahrscheinlich wenig, sobald die Socket Failures wieder auftreten?
 
You must log in or register to reply here.
Back
Top