CPU Hole -> Nach einem Tag Faktor 10 langsamer? [Solved]

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
p90
User
Beiträge: 198
Registriert: Donnerstag 22. Juli 2010, 17:30

Hi,


habe folgendes Problem:

Habe ein kleines Script mit dem ich per VISA und GPIB Daten von einem Oszi nehme.
Danach schreibe ich diese Daten als einzelne Dateien in einen Ordner.
Problem ist nun, das nach einem Tag die rate mit der ich Daten nehme ca. um einen Faktor 10 bis 100 einbricht.
Der CPU ist statt 3% am ersten Tag zu 100% ausgelastet.
Ein Neustart des Systems und des Scripts helfen auch nichts.
Deshalb dachte ich zuerst, das vlt NTFS nicht mit vielen (>100000) Dateien pro Ordner umgehen kann.
Habe dann ein kleines Testprogramm geschrieben das möglichst schnell Dateien anlegt. Bei diesem sehe ich diesen Effect nicht.
Auch mehr Ram wird nicht belegt, zumindest zeigt der Taskmanager nichts an.
Hier mein Programm das die Probleme macht:

Code: Alles auswählen

import visa
import csv

oszi = visa.instrument("GPIB::7") #get oszi for whole programm
del oszi.timeout
#timeout is removed because we might have reeally low trigger rates.
#if time between triggers is bigger as timeout, we will lose connection to the oszilloscope!
#oszi would need a reboot to recover!

#set oszi to what we need
#but leave other settings unchanged so
#you can still configure by "hand" on the
#frontpanel of oszi

def writecsv(filename, header, data):
	with open("directory/%s.csv" % filename, "w") as fobj:
		writer = csv.writer(fobj, delimiter=',', lineterminator='\n')
		known_types = ["Type:", "Points:", "Count:", "XInc:", "XOrg:", "XRef:", "YData range:", "YData center:", "Coupling:", "XRange:", "XOffset:", "YRange:", "YOffset:", "Date:", "Time:", "Frame:", "Acq mode:", "Completion:", "X Units:", "Y Units:", "Max bandwidth:", "Min bandwidth:"]
		
		#make sure that custom headers will
		#be printed after the predefined from oszi
		a = set(known_types)
		b = set(header.keys()) 		

		formatted_header = [["".join([key, (15-len(key)) * " ", str(header[key])])] for key in known_types]
		formatted_header.extend([["".join([key, (15-len(key)) * " ", str(header[key])])] for key in b.difference(a)])
		writer.writerows(formatted_header)
		writer.writerow(["Data:"])
	       	writer.writerows(data)


def create_header(header):
	d = dict()
        mache etwas umformungen sodas:
        d[headername] = headervalue ist
	return d


oszi.write("Digitize") #wait for new event
events = 999999999
for j in xrange(1, events):
	oszi.write("Digitize")
	id = str(j).zfill(9)
	print id
	#now get data
	header = create_header(oszi.ask(":WAVeform:PREamble?").split(","))
	y = oszi.ask(":WAVeform:DATA?").split(",")
	xorig = float(header["XOrg:"])
	xinc = float(header["XInc:"])
	data = [["%E" % (float(xorig) + i * float(xinc)), y[i]] for i in xrange(len(y)) ]
	
	#now we have to connvert and save to disk
	#maybe store in ram somehow before doing that?

	writecsv("Prefixfilename" + id, header, data)	
Mein Testprogramm sah so aus:

Code: Alles auswählen

for i in xrange(10000000):
	with open("speed/%s.csv" % str(i), "w") as fobj:
		print i
Irgendwie muss der Fehler mit der Anzahl der Dateien in meinem Ordner zusammenhängen.
Aber ka wie und auch ka wie ich das behebe und auch ka warum mein Testprogramm dann nicht das selbe verhalten zeigt.

Kann mir jamend einen Tipp geben?
Zuletzt geändert von p90 am Donnerstag 19. Mai 2011, 14:07, insgesamt 1-mal geändert.
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

Welcher Prozess ist denn laut Taskmanager der Verursacher der 100% Auslastung?

Es sieht mir nicht danach aus, als läge dein Problem in der writecsv-Funktion, trotzdem habe ich sie ein ein wenig speichersparender gemacht, vielleicht hilft es ja ein bisschen:

Code: Alles auswählen

from itertools import chain

known_types = set(['Type:', 'Points:', 'Count:', 'XInc:', 'XOrg:', 'XRef:',
    'YData range:', 'YData center:', 'Coupling:', 'XRange:', 'XOffset:',
    'YRange:', 'YOffset:', 'Date:', 'Time:', 'Frame:', 'Acq mode:',
    'Completion:', 'X Units:', 'Y Units:', 'Max bandwidth:', 'Min bandwidth:'
])

def writecsv(filename, header, data):
    all_types = chain(known_types, known_types.difference(header.keys()))
    formatted_header = (['%-15d%s' % (key, header[key])] for key in all_types)
    with open('directory/%s.csv' % filename, 'w') as fobj:
        writer = csv.writer(fobj, delimiter=',', lineterminator='\n')
        writer.writerows(chain(formatted_header, ['Data:'], data))
Falls sich herausstellen sollte, dass es doch an den viele Dateien liegt, überleg dir, ob du vielleicht eine Datenbank verwenden könntest.

Gruß,
Mick.
In specifications, Murphy's Law supersedes Ohm's.
Mad-Marty
User
Beiträge: 317
Registriert: Mittwoch 18. Januar 2006, 19:46

Probiere doch einmal den oszi wieder freizugeben und bei bedarf wieder zu holen.
Ich würde mal vermuten der greift auf externe C-Libs zu, und die haben ggf. ein memory leak.
p90
User
Beiträge: 198
Registriert: Donnerstag 22. Juli 2010, 17:30

Hi,

also erstmal, der Process der sich da die 100% zieht ist einfach der python interpreter. Also das was im Taskmanager als "python" angezeigt wird.
Ich starte wie gesagt bei 0-3% und nach einem Tag ist er bei 100% angekommen.
Systemprocess etc. ist alles auf 0% denke also nicht das es irgendwas IO-related ist (die Festplattenaktivitätsanzeige blitzt auch immer nur auf wenn eine Datei geschrieben wird und ist nicht dauerhaft an)
Am Oszi liegt es auch nicht.
Wenn ich einfach mein Programm beende, auf einen neuen leeren Ordner umschwenke geht es wieder schnell.
Mein Programm aber einfach zu beenden und wieder den bereits vollen Ordner zu verwenden hingegen führt dazu das es immer noch langsam ist.
Speicher ist nach Taskmanger bei konstanten 25MB und es findet auch kein Swappen statt.
Hätte wie gesagt auf NTFS getippt aber dann müsste doch auch mein Testprogramm diesen Fehler haben oder?
Und wenn ich irgendwo ein verstecktes Memory hole hätte müsste doch das beenden des Scriptes und ein neustart dies beheben. Tut es nur leider nicht.
Bin total ratlos was hier schief geht.
Datenbank kann ich hier leider nicht verwenden da ich kompatible mit der Ausgabe des Oszis sein muss und das gibt die Daten leider nun mal als einzelne Dateien aus.

@Mad-Marty
Wie meinst du das mit dem freigeben des Oszis?
Vlt zur Erklärung.
Immer wenn ich dem Oszi ein Digitize schicke wartet dieses auf den nächsten Trigger (der kommt von außen) und nimmt dann eine Waveform auf die ich dann aus seinem Speicher auslesen kann. Deshalb bleibt das Oszi in diesem Moment stehen, ignoriert also andere Daten. Erst wenn ich die Daten weggeschrieben habe gebe ich ihm ein neues Digitize und nehme eine neue Waveform auf. Und das geht halt auch schon schön schnell. Ca. 10Hz am Anfang aber anch nem Tag dann halt plötzlich 0,1 oder 0.01Hz.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Ich wäre sehr skeptisch, dass irgendein Betriebssystem es aushält, knapp eine Milliarde Dateien in einem einzelnen Verzeichnis zu verwalten. Wenn es denn so viele einzelne Dateien sein müssen, dann lege 1000 Verzeichnisse an, in diesen jeweils 1000 Unterverzeichnisse und darin dann jeweils 1000 Dateien. Der bessere Ansatz wäre aber IMHO, eine Datenbank zu benutzen, denn diese kann die 1 Mrd Datensätze dann in eine Datei schreiben.

Dein Testprogramm stellt die "Wirklichkeit" auch nicht genug da. Zum einen sind es nur 10 Millionen Dateien, zum anderen sind sie alle leer. Ich tippe darauf, dass NTFS ähnlich wie Unix-Dateisysteme leere (oder sehr kleine) Dateien anders verarbeiten, als "normale". Dort spart man sich z.B. das Anlegen von Datenblöcken.

Stefan
p90
User
Beiträge: 198
Registriert: Donnerstag 22. Juli 2010, 17:30

Hi,

die eine Milliarde ist ja nur die obere Grenze.
Musste mir halt irgendeine "große" Zahl nehmen damit ich die in nächster Zeit auch nicht ausschöpfe.
Wir bewegen uns hier eher im 200k Bereich. Das es da langsamer wird ist klar, aber doch nur beim lesen.
Das mit den Ordnern kann ich ausprobieren, da wir eh etwas ähnliches vorher hatten (das Oszi kann selber immer 1000 Files wegspeichern pro Ordner, halt von 000-999 deshalb auch die von mir größer gewählte Zahl damit der nächste nicht in das selbe Problem läuft.)
Mal sehen ob es was bringt

[EDIT]
Hm, vermutlich ist es wohl doch NTFS was mir da den Tag versaut.
Hab hier mal einen Test gefunden.
http://www.frank4dd.com/howto/various/m ... er-dir.htm
Das könnte genau das Erklären was ich sehe. Aber dann sollte doch auch das Testprogramm probs machen...
Antworten