Deusch-Schwäbisch-Deutch

Super Dictionary :)  http://www.happes.net/schwaebisch/default.asp?v=g

 

Verteilung der Dateien im Filesystem - wie groß sind meine Dateien?

Wenn man mal eine Analyse über Dateigrößen eines bestimmten Verzeichnisses bekommen will kann man den Unixbefehl find verwenden:

find c:\foo -type f -printf "Size:\t%s\tName:\t%p\r\n" > output.txt

Find ist Bestandteil der Windows Gnutools, die IMO jeder der Windows Server betreibt installiert haben sollte, genauso wie die sysinternals suite :).

output.txt sieht dann folgendermaßen aus:

Size: 746 Name: c:\foo\1.txt
Size: 603 Name: c:\foo\bar\2.txt
Size: 2077 Name: c:\foo\bar\3.txt

Den output kann man leicht in Excel analysieren (Pivotchart!), mit Pipes an andere programme weiterleiten (grep z.B.) oder mit eigenen Scripten (Perl bietet sich an) weiterverarbeiten. Beispielsweise kann man so eine Größenverteilung der Dateien zu ermitteln (Wieviel Prozent der Dateien sind eigentlich kleiner als x Byte, Wieviel Prozent davon sind Textfiles etc).

Windirstat, DF, DU, LS oder DIR /s können das alles nicht leisten, weil der output entweder die Verzeichnisse mit listet, Summen für Unterverzeichnisse bildet oder einfach für die weitere Verarbeitung ungeeignet ist.

XSS Cheat Sheet

Für alle die ihren XSS Payload nicht selbst schreiben wollen oder
können, hier gibt es schon einige Standardtemplates:

http://ha.ckers.org/xss.html

DataProtector und Backward Compatibility beim SQL Server 2008

Ich lese hier grade interessantes zu SQL Server 2008 und Data Protector:

 

Anscheinend benötigt man das SQL 2005 Backward Compatibility Pack damit man mit Data Protector Backups auf SQL Server 2008 machen kann. Offensichtlich geht noch nichtmal der connection check wenn das nicht der Fall ist.

 

http://headadmin.net/?p=225

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1270026292340+28353475&threadId=1189523

 

 

 

 

NIC Speed VMWare ESX

Interessante Info zu Speed und Autonegotiation bei Intel Pro 1000 MT:

Wir haben hier mehrere VMWare Guests (die auf ESX laufen). Alle haben die virtuelle Netzwerkkarte „Intel Pro 1000 MT“, die eigentlich ja 1000 Mbit unterstützt. Auf der NIC kann allerdings sowohl mit dem Microsoft Treiber als auch mit dem Intel Treiber nur maximal 100 Mbit Full Duplex einstellen.(Der Virtuelle Switch, ESX Host NIC‘s und der Cisco Routingswitch sind natürlich allesamt auf 1 Gbit FDX eingestellt, Autonegotiate ist aus).

Trotzdem kann man auf den virtuellen Karten maximal 100MBs/Full Duplex einstellen. Die 1000MBs/Fdx einstellung die wir von NICs normalerweise gewohnt sind, gibt es nicht. Die 1000 MBs erreicht man nur, wenn man die Speed auf „Auto“ stellt was wir auf echter Hardware ungern machen, weil es immer wieder zu Problemen mit Verbindungsabbrüchen kam.

Jetzt sind diese Karten ja bekannterweise keine echte Hardware, sondern von ESX vollständig virtualisiert. In wirklichkeit ist es total egal ist, welche Speed in den VMWare Guests eingestellt ist, der ESX Host bestimmt die Geschwindigkeit. Wenn dort 1000 Gbit eingestellt sind werden die auch benutzt.

Wir haben es gestestet und kamen auf 317 MB/min bei 100 Mbit und 312 MB/Min bei Auto (1000 Mbit). Die Differenz von 5 MB ist zu vernachlässigen, die müsste grob um den Faktor 10 unterschiedlich sein.

Grund (laut diesen Threads) ist dass die Speed auf Layer 2 abläuft (Ethernet), die allerdings in der VM keine Rolle spielt weil die Kommunikation dort nur über den TCP/IP Stack abläuft (layer 3+4). Die Argumentation steht aber auf wackeligen Füßen wie ich finde, weil der Treiber die Einstellung zumindest an’s Layer 2 kommunizert, da es ein „echter“ Treiber ist und nicht von VMWare kommt. Dass die virtuelle Hardware die diese Einstellung dann ignoriert weiß der Treiber nicht – allerdings läuft die Kommunikation nicht nur auf Layer 3 + 4, dazu wären spezielle von VMWare implementierte TCP/IP stacks (und VMWare Treiber) notwendig. IMO gibt es durchaus einen Layer2, der die Kommunkiation übernimmt, auch wenn dieser durch ESX virtualisiert ist.

Wichtig ist nur: Dem Guest kann’s egal sein, der ESX Host bestimmt die Geschwindigkeit, egal ob 10, 100 oder 1000 MBit auf dem Guest eingestellt sind :)

Ubuntu Linux Bash History Suche PageUp

Ein nettes Feature dass bei Ubuntu bisher immer standardmäßig
ausgeschalten ist, ist die Suche in der bash_history. Bei anderen
Linuxen war das bisher mit PageUP/Down voreingestellt:

z.B.: Man hat eine Konsole und tippt seinen Text ein:

"foo"

Dann PageUP (autocomplete aus der bash_history) und alle Befehle die in
der bash_history vorkommen und mit foo beginnen werden vorgeschlagen:

"foo bar1"
"foo bar2"

Dieses Verhalten schaltet man einfach in der /etc/inputrc (für alle
Benutzer) oder in der ~/.inputrc (für den angemeldeten Benutzer) ein
oder aus:

# alternate mappings for "page up" and "page down" to search the history
"\e[5~": history-search-backward
"\e[6~": history-search-forward

Übrigens: die Suche in der bash history geht auch mit CTRL-r. Ist aber
etwas umständlicher.

Microsoft 64 Bit Speicherverwaltung

Microsoft hat bei der x64 Implementierung ihrer Speicherverwaltung offensichtlich einiges verkackt. Offensichtlich haben sie die x64 Implementierung nicht richtig durchdesigned und einfach mal die normale 32 Bit Verwaltung genommen und aufgebohrt. Leider hat Microsoft dabei vergessen, dass das der System File Cache jetzt nicht mehr so limitiert ist wie früher *muahaha*. Ich erklärs mal kurz:

Der System Cache ist teil des Working Set und liegt im Kernel Address Space, der in jeden Prozess gemappt wird. (bei 32 Bit ist die der Kernel Address Space überlichweise 2 GB (bei /3GB in der Boot.ini liegt er sogar nur bei 1 GB!). Das war früher kein großes Problem, weil der Platz beschränkt war.

Bei 64 Bit gibt es hier auf einmal das Problem dass der Kernel Address Space faktisch keiner Limitierung mehr unterliegt. Das hat Microsoft offensichtlich vergessen: Beim Kopieren großer Files oder während Backups wächst der Cache jetzt ständig an - er hat ja keine Grenze mehr (bzw diese Grenze liegt so hoch dass sie das physical RAM übersteigt). Irgendwann ist alles RAM für den Cache aufgebraucht und andere Prozesse werden zum pagout gezwungen und die Performace bricht dramatisch ein.

Deshalb haben dann so unwesentliche Systeme wie SAP (die man meist auf x64 laufen lässt) auf einmal so massive Performanceprobleme, wenn ein Backup läuft (oder auch einfach mal so im Lauf der Zeit). SAP supported deshalb übrigens CRM nur noch auf Unix und nicht auf Windows x64.


SAP:

• https://service.sap.com/sap/support/notes/1416152

MS:

• http://support.microsoft.com/default.aspx?scid=kb;EN-US;976618
• http://blogs.msdn.com/psssql/archive/2007/10/18/do-i-have-to-assign-the-lock-privilege-for-local-system.aspx
• http://blogs.msdn.com/ntdebugging/archive/2007/11/27/too-much-cache.aspx
• http://blogs.msdn.com/ntdebugging/archive/2009/02/06/microsoft-windows-dynamic-cache-service.aspx