[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dateikopien zwecks Debugging speichern - oder auch nicht. Aber wie?



Am 22.01.2017 um 20:52 schrieb Peter Ludikovsky:

>> Das Original mag es nicht bemerken, aber irgendwo geht dann doch im
>> Zweifel trotzdem was hops, wenn das nicht schnell genug entgegengenommen
>> wird.
>> Sprich, entweder habe ich einen Stapel Tasks auf der Maschine laufen,
>> die nicht fertig werden, und damit das RAM blockieren, das ich für die
>> Verarbeitung der Jobs brauche, oder es werden Pakete verworfen und auf
>> meinem Mitschnitt-Host kommen unvollständige Daten an, so dass ich keine
>> verlässliche Kopie habe.
> 
> Also ersteres mit großer Warscheinlichkeit nicht, wenn direkt im Kernel
> das IP Paket geklont & sofort wieder raus geschickt wird. Und wenn der
> Mittschnitt-Host schnell genug ist kann der ohne Probleme die Daten
> annehmen & speichern.

Ich sehe das Problem nicht in der Verarbeitungsgeschwindigkeit der
lokalen Mascnine, sondern in
- Netzwerkverfügbarkeit zum Mitschnitt-Host
- Netzwerkgeschwindigkeit zum Mitschnitt-Host
- Verarbeitungsgeschwindigkeit des Mitschnitt-Hosts


>>> Alternativ fällt mir jetzt ein, dass auch die Möglichkeit mit dem
>>> Netzwerk-Mount ohne Performance-Probleme möglich wäre, du musst nur den
>>> Job, der die Daten schreibt, per fork() oder & (bei Shell-Script)
>>> abspalten, dann läuft das unabhängig.
>>
>> Auch da steht dann trotzdem noch der Job im RAM rum, wird nicht fertig,
>> und bremst/beschädigt (weil irgendwann der Out-of-Memory-Killer
>> zuschlägt) dann nachfolgende Jobs.
> 
> Muss nicht sein. Ich kann zu wenig C um das per fork()/pthreads zu
> basteln, aber in der Bash geht das relativ leicht:
>     ( cp <src> <dst> ) &          # Job im Hintergrund starten /
>                                   # "fork()"
>     bpid=$!                       # Background-PID speichern
>     ( sleep 10; kill -9 ${bpid} ) # Wenn nach 10 Sekunden cp nicht
>                                   # fertig ist -> Abbruch
> Kann etwas mehr Fehler- und Umgebugsprüfung vertragen, aber die
> prinzipielle Funktionsweise sollte klar sein.

Ne, genau das ist halt auch nix. Was auf dem Mitschnitt-Host ankommt,
muss schon auch komplett sein.
Sinn und Zweck im Debugging-Fall ist ja, einen "Replay" fahren zu
können. Wenn der Datensatz dann nach 10 Sekunden abbricht, kommt nur
Murks raus.


> Was allerdings nicht funktionieren wird ist dass du hier in der Liste
> eine Frage zu einer speziellen Problemstellung stellst & eine
> schlüsselfertige Lösung bekommst.

Dass sie mir keiner entwickelt, schon klar, das erwarte ich auch nicht.
Aber es soll vorkommen, dass Leute eine Frage stellen wie "Ich brauch da
was, um meine Lasten von A nach B zu befördern, und mit dem Schlitten
ist das auf dem Kies so unbequem und kräftezehrend, gibt's da nichts
leichteres?", und ein anderer antwortet "Doch, klar, nennt sich Rad."
Weil Wald, Bäume, und so.

Gruß
Stefan

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: