Beide Seiten der vorigen RevisionVorhergehende Überarbeitung | |
de:services:storage_services:backup:tsm:anleitungen:memoryefficient [2025/03/13 08:25] – [Hintergrund] jbruene | de:services:storage_services:backup:tsm:anleitungen:memoryefficient [2025/03/13 08:48] (aktuell) – [Abhilfe] jbruene |
---|
TSM/ISP bietet Möglichkeiten, die Leistung zu optimieren, neben allgemeinen Empfehlungen (z.B. RAM aufstocken, mittels //Exclude.Dir// die Anzahl der Datei zu reduzieren) auch Optionen, die den virtuellen Dateibaum teilen und/oder diesen auf Festplatte auslagern -- und dabei wesentlich effizienter als das Swappen sind. | TSM/ISP bietet Möglichkeiten, die Leistung zu optimieren, neben allgemeinen Empfehlungen (z.B. RAM aufstocken, mittels //Exclude.Dir// die Anzahl der Datei zu reduzieren) auch Optionen, die den virtuellen Dateibaum teilen und/oder diesen auf Festplatte auslagern -- und dabei wesentlich effizienter als das Swappen sind. |
| |
Die Optimierung wird über die Option //MEMORYEFficientbackup [Yes|DISKCACHEMethod]// gesteuert (einzutragen in die //dsm.sys// bzw. //dsm.opt//) und erlaubt zwei Varianten: | Die Optimierung wird über die Option //[[https://www.ibm.com/docs/de/storage-protect/8.1.25?topic=reference-memoryefficientbackup|MEMORYEFficientbackup]] [Yes|DISKCACHEMethod]// gesteuert (einzutragen in die //dsm.sys// bzw. //dsm.opt//) und erlaubt zwei Varianten: |
* ''MEMORYEFficientbackup Yes''\\ sofern mehrere //FILESPACES// existieren, werden die virtuellen Dateibäume nacheinander aufgebaut und somit weniger Hauptspeicher gleichzeitig genutzt.\\ __ABER__: Diese Einstellung macht die Nutzung von mehreren parallelen Datenströmen zunichte, da immer nur ein Filespace (und damit ein Datenstrom) bearbeitet wird. Sie ist auch **wirkungslos, wenn nur ein Filespace** existiert. | * ''MEMORYEFficientbackup Yes''\\ Die virtuellen Dateibäume werden verzeichnisweise aufgebaut und im Backup nacheinander abgearbeitet. Dadurch ist weniger Hauptspeicher notwendig, als wenn zuerst der gesammte virtuelle Dateibaum erstellt wird. |
* ''MEMORYEFficientbackup DISKCACHEMethod'' und ''DISKCACHELocation <PFAD>''\\ Der virtuelle Dateibaum wird in einen -- mit dem Parameter //DISKCACHELocation// angegebenen -- Pfad ausgelagert. Dieser sollte | * ''MEMORYEFficientbackup DISKCACHEMethod'' und ''DISKCACHELocation <PFAD>''\\ Der virtuelle Dateibaum wird in einen -- mit dem Parameter //DISKCACHELocation// angegebenen -- Pfad ausgelagert. Dieser sollte |
* selbst nicht gesichert werden. Also per //exclude.dir <PFAD>// ausgeschlossen werden, am besten sogar auf eine eigene Festplatte ausgelagert werden, mindestens aber in eine eigene Partition gelegt werden. | * selbst nicht gesichert werden. Also per //exclude.dir <PFAD>// ausgeschlossen werden, am besten sogar auf eine eigene Festplatte ausgelagert werden, mindestens aber in eine eigene Partition gelegt werden. Falls //DISKCACHELocation// nicht definiert wird, wird als Default das zu sichernde Dateisystem benutzt und der benutzte Pfad in der Backup-Session aus dem Backup ausgeschlossen. |
* auf eher performantem Speicher liegen, also nicht auf einem NFS-/CIFS-Share vom //"alten, längst abgeschriebenem Fileserver"//. | * auf performantem Speicher liegen |
* z.B.\\ ''DISKCACHELocation "D:TSMCache\NodeX\"''\\ ''MEMORYEFficientbackup DISKCACHEMethod'' | * z.B.\\ ''DISKCACHELocation %%"%%D:\TSMCache\NodeX\%%"%%''\\ ''MEMORYEFficientbackup DISKCACHEMethod'' |
* **Hinweis:** Bei Windows-Clients ggf. den Pfad mittels ''"'' maskieren | * **Hinweis:** Bei Windows-Clients ggf. den Pfad in Quotes (%%"%%) setzen |
| |
**WICHTIG**:\\ | **WICHTIG**:\\ |
Der Platzbedarf für die Auslagerung des Dateibaumes kann erheblich sein, also bitte anfangs und auch regelmäßig prüfen, ob der zur Verfügung gestellte Platz ausreicht! | Der Platzbedarf für die Auslagerung des Dateibaumes kann erheblich sein, also bitte anfangs und auch regelmäßig prüfen, ob der zur Verfügung gestellte Platz ausreicht! |