TeamDrive Forums

Hallo,

ich habe testweise den tdpsd auf einem Linux Server (32Bit) installiert, nachdem das Syncronisieren von ca. 4.5GB mit WebDAV (über SSL) reproduzierbar den MacOS Client zum Absturz gebracht hat.
Mit dem MacOS Client habe ich dann ca. 4.5GB Daten raufgeladen auf den tdsp space und auf einem anderen Mac syncronisiert, ohne Probleme bei der Last auf dem Server.

Nun hat ein Mitglied des spaces die Syncronisation mit dem Windows Client gestartet, und obwohl er nur mit ca 300kb/s syncronisiert ist die Last auf dem System extrem:



tdpsd ist Version 1.0.17
Server ist ein CentOS 5.4 32Bit

Können Sie das reproduzieren?
Danke!

Hallo,

ich kann die sehr hohe Ressourcenauslastung unter einem Ubuntu Server 64 Bit bestätigen.
Es werden bis zu 22 Threats von tdspd gestartet und die Last ist extrem hoch.

Gruß

S. Fu.

Hallo,

die Anzahl der Threads is abhängig von der Menge der parallelen Zugriffe. Ein TeamDrive-Client verwendet per Default maximal 2 gleichzeitige Verbindungen. Aber je mehr User in einen Space eingeladen werden, desto mehr gleichzeitige Verbindungen werden ggf. benötigt. Die Menge der Verbindungen kann man in der tdps.config des TeamDrive Personal Servers konfigurieren (maximum-connections).

Unabhängig davon sollte die CPU-Last aber nicht so hoch ansteigen. Nach einem Neustart des TDPS dürfte dies vermutlich wieder normal sein. Wir werden versuchen das bei uns einmal zu reproduzieren, um zu gucken, was die CPU-Last verursacht.

Könnten Sie uns einmal Ihre tdps.log-Dateien an support@teamdrive.net zuschicken? Ggf. ist dort was zu finden.

Grüße E. Prühs

Wir vermuten als Ursache, dass der TeamDrive Personal Server in einer schlechten TCP-Verbindung fest hängt und dadurch die hohe CPU-Last verursacht wird. Leider können wir dies nicht so einfach reproduzieren. Deshalb die Bitte, ob Sie dieses Script bei sich als Shell-Script einmal unter dem Namen "pmp" abspeichern können und es bei Auftreten der CPU-Last mit folgenden Parametern aufrufen:

pmp <pid> <probe-count> <probe-pause>

<pid> = Prozess-ID des TeamDrive Personal Servers
<probe-count> = Anzahl der Aufrufe
<probe-pause> = Pause in Sekunden zwischen den einzelnen Aufrufen

Beispiel: pmp 1925 10 2

Der Ouput erzeugt einen Strack-Trace wo der TeamDrive Personal Server gerade hängt.


Hier der Script-Inhalt:

#!/bin/bash
mpid=$1
nsamples=$2
sleeptime=$3
for x in $( seq 0 $nsamples) ; do
gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p $mpid
sleep $sleeptime
done | \
awk 'BEGIN { s = ""; } /Thread/ { print s; s = ""; } /^\#/ { if (s != "" ) { s = s "," $4} else { s = $4 } } END { print s }' - | \
sort | uniq -c | sort -r -n -k 1,1

Vielen Dank für das script, ich werde es dann beim nächsten Mal ausführen.

Ich konnte den Fehler heute mit einem Windows Client nicht reproduzieren, eine Syncronisation mit hoher Datenrate erzeugte keine signifikante Last auf dem Server.
Ihre Erklärung klingt somit für mich sehr plausibel.