Bei der Ausgabe von Top sehe ich, dass fast 2,5 G an Hauptspeicher verwendet werden ... aber für was?? Wenn ich Virtual zusammenzähle komme ich auf 562 MB bei Res auf 363 MB ... aber nie auf 2,5 G Was frisst denn hier? Tasks: 53 total, 1 running, 52 sleeping, 0 stopped, 0 zombie Cpu(s): 11.0% us, 1.3% sy, 0.0% ni, 85.9% id, 1.7% wa, 0.0% hi, 0.0% si Mem: 2596544k total, 2524844k used, 71700k free, 72464k buffers Swap: 1048552k total, 0k used, 1048552k free, 2091128k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 16 0 692 264 224 S 0.0 0.0 0:01.00 init 2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 3 root 10 -5 0 0 0 S 0.0 0.0 0:00.01 events/0 4 root 10 -5 0 0 0 S 0.0 0.0 0:00.03 khelper 5 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kthread 9 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid 337 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0 372 root 15 0 0 0 0 S 0.0 0.0 0:00.34 pdflush 375 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0 374 root 15 0 0 0 0 S 0.0 0.0 0:00.08 kswapd0 965 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod 1143 root 10 -5 0 0 0 S 0.0 0.0 0:00.07 reiserfs/0 2057 root 13 -4 4172 1492 1048 S 0.0 0.1 0:00.58 udevd 2368 messageb 17 0 5872 2372 1952 S 0.0 0.1 0:00.19 dbus-daemon 2416 root 16 0 2004 584 496 S 0.0 0.0 0:00.00 resmgrd 2818 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 khubd 4110 nobody 23 0 1532 480 404 S 0.0 0.0 0:00.00 portmap 4187 root 16 0 1488 532 464 S 0.0 0.0 0:00.00 acpid 4280 root 17 0 5240 2124 1736 S 0.0 0.1 0:00.18 sshd 4360 ldap 18 0 34752 4768 2996 S 0.0 0.2 0:00.26 slapd 4480 named 16 0 31112 3972 2964 S 0.0 0.2 0:00.00 named 4486 mdnsd 16 0 4456 2404 1884 S 0.0 0.1 0:00.02 mdnsd 4495 root 16 0 15372 2600 1996 S 0.0 0.1 0:00.07 nscd 4583 root 16 0 5140 1632 1324 S 0.0 0.1 0:00.01 master 4638 nobody 16 0 3216 1276 1056 S 0.0 0.0 0:00.02 nrpe 4639 root 16 0 1780 620 536 S 0.0 0.0 0:00.00 cron 4685 root 16 0 4904 3568 1544 S 0.0 0.1 0:00.46 hald 4696 root 18 0 1792 580 504 S 0.0 0.0 0:00.00 hald-addon-acpi 4740 root 16 0 1792 612 536 S 0.0 0.0 0:00.04 hald-addon-stor 4763 root 16 0 5080 3872 1512 S 0.0 0.1 0:00.00 python2.3 4764 zope 16 0 322m 284m 2832 S 0.0 11.2 9:30.86 python2.3 4775 root 18 0 1924 616 548 S 0.0 0.0 0:00.04 mingetty 4776 root 18 0 1928 600 532 S 0.0 0.0 0:00.00 mingetty 4974 root 15 0 8388 2436 1960 S 0.0 0.1 0:00.45 sshd 4977 root 16 0 4128 1876 1380 S 0.0 0.1 0:00.12 bash 5107 root 15 0 0 0 0 S 0.0 0.0 0:00.00 pdflush 5169 root 15 0 8404 2464 1960 S 0.0 0.1 0:01.20 sshd 5174 root 15 0 4132 1908 1400 S 0.0 0.1 0:00.26 bash 5402 root 15 0 8204 3012 2500 S 0.0 0.1 0:02.05 sshd 5405 root 17 0 3864 1444 1188 S 0.0 0.1 0:00.06 bash 5508 root 16 0 1980 812 648 S 0.0 0.0 0:00.00 syslog-ng 5511 root 15 0 1624 604 412 S 0.0 0.0 0:00.00 klogd 7541 postfix 16 0 5108 1552 1260 S 0.0 0.1 0:00.00 pickup 7542 postfix 16 0 5144 1580 1284 S 0.0 0.1 0:00.00 qmgr 8200 root 16 0 5568 2212 1384 S 0.0 0.1 0:00.00 httpd2-prefork 8201 wwwrun 16 0 5704 2388 1488 S 0.0 0.1 0:00.00 httpd2-prefork 8202 wwwrun 16 0 5836 2476 1512 S 0.0 0.1 0:00.00 httpd2-prefork 8203 wwwrun 16 0 5704 2368 1480 S 0.0 0.1 0:00.00 httpd2-prefork 8204 wwwrun 15 0 5836 2524 1560 S 0.0 0.1 0:00.00 httpd2-prefork 8205 wwwrun 15 0 5704 2368 1484 S 0.0 0.1 0:00.00 httpd2-prefork 8221 wwwrun 16 0 5836 2464 1512 S 0.0 0.1 0:00.00 httpd2-prefork 8222 wwwrun 16 0 5700 2304 1436 S 0.0 0.1 0:00.00 httpd2-prefork 8429 root 15 0 2108 872 664 R 0.0 0.0 0:00.00 top
Martin Hochreiter schrieb:
Bei der Ausgabe von Top sehe ich, dass fast 2,5 G an Hauptspeicher verwendet werden ... aber für was?? Wenn ich Virtual zusammenzähle komme ich auf 562 MB bei Res auf 363 MB ... aber nie auf 2,5 G
Was frisst denn hier? Tasks: 53 total, 1 running, 52 sleeping, 0 stopped, 0 zombie Cpu(s): 11.0% us, 1.3% sy, 0.0% ni, 85.9% id, 1.7% wa, 0.0% hi, 0.0% si Mem: 2596544k total, 2524844k used, 71700k free, 72464k buffers Swap: 1048552k total, 0k used, 1048552k free, 2091128k cached
Da steht es doch: 2091128k cached Und free wird Dir dasselbe sagen. Speicherprotz! ;-) Freundlicher Gruß Werner Flamme
Hi Werner! Da fehlt mir noch der Zusammenhang - Cached bedeutet dass 2 G für Systemcache verwendet werden und nicht durch einen Prozess gefressen werden oder wie? lg
Martin Hochreiter schrieb:
Bei der Ausgabe von Top sehe ich, dass fast 2,5 G an Hauptspeicher verwendet werden ... aber für was?? Wenn ich Virtual zusammenzähle komme ich auf 562 MB bei Res auf 363 MB ... aber nie auf 2,5 G
Was frisst denn hier? Tasks: 53 total, 1 running, 52 sleeping, 0 stopped, 0 zombie Cpu(s): 11.0% us, 1.3% sy, 0.0% ni, 85.9% id, 1.7% wa, 0.0% hi, 0.0% si Mem: 2596544k total, 2524844k used, 71700k free, 72464k buffers Swap: 1048552k total, 0k used, 1048552k free, 2091128k cached
Da steht es doch: 2091128k cached
Und free wird Dir dasselbe sagen. Speicherprotz! ;-)
Freundlicher Gruß Werner Flamme
Martin Hochreiter schrieb:
Bei der Ausgabe von Top sehe ich, dass fast 2,5 G an Hauptspeicher verwendet werden ... aber für was?? Wenn ich Virtual zusammenzähle komme ich auf 562 MB bei Res auf 363 MB ... aber nie auf 2,5 G
Was frisst denn hier? Tasks: 53 total, 1 running, 52 sleeping, 0 stopped, 0 zombie Cpu(s): 11.0% us, 1.3% sy, 0.0% ni, 85.9% id, 1.7% wa, 0.0% hi, 0.0% si Mem: 2596544k total, 2524844k used, 71700k free, 72464k buffers Swap: 1048552k total, 0k used, 1048552k free, 2091128k cached
Alles im grünen Bereich: Linux nutzt den Speicher wenn er vorhanden ist. Zur Not bleibt dann auch mal Zeugs im Speicher das vielleicht noch mal gebraucht werden könnte . Solange dein System nicht swappt hast du ausreichend Speicher im System. Gruß
Alles im grünen Bereich: Linux nutzt den Speicher wenn er vorhanden ist. Zur Not bleibt dann auch mal Zeugs im Speicher das vielleicht noch mal gebraucht werden könnte . Solange dein System nicht swappt hast du ausreichend Speicher im System.
Gruß
Na dann is gut (wieder was dazugelernt) ... dank euch!
Ralf Prengel, Freitag, 28. April 2006 09:37:
Solange dein System nicht swappt hast du ausreichend Speicher im System.
Das kann so nicht ganz stimmen. Ich betreibe u.a. einen Fileserver, auf dem nix anderes als samba und ein kleiner bind (=caching-only) läuft. RAM hat die Kiste 4 GB, damit viel gecached werden kann. Trotzdem fängt die Maschine nach einiger Zeit an zu swappen. Es ist nicht viel, und es zieht auch die Performance nicht runter. Aber irgendwas veranlaßt die Maschine trotzdem zum swappen, obwohl sie sicherlich genug RAM hat. -- Andre Tann
Andre Tann wrote:
Ralf Prengel, Freitag, 28. April 2006 09:37:
Solange dein System nicht swappt hast du ausreichend Speicher im System.
Das kann so nicht ganz stimmen. Ich betreibe u.a. einen Fileserver, auf dem nix anderes als samba und ein kleiner bind (=caching-only) läuft. RAM hat die Kiste 4 GB, damit viel gecached werden kann. Trotzdem fängt die Maschine nach einiger Zeit an zu swappen. Es ist nicht viel, und es zieht auch die Performance nicht runter. Aber irgendwas veranlaßt die Maschine trotzdem zum swappen, obwohl sie sicherlich genug RAM hat.
Ich glaube, ihr redet etwas aneinander vorbei. Ralf schrieb ja nicht, dass kein Swapping erfolgt, wenn genuegend Speicher vorhanden ist - er schrieb lediglich, dass bei dem aktuell gegebenen Problem (siehe urspruengliche Info von Martin) nichts geswappt wurde, daher es auch kein Speicherengpass und damit Performance-Probleme geben sollte. In der Tat kann der Kernel selbst bei sehr grosszuegig dimensioniertem RAM (das ist bei Dir ja gegeben) Speicherseiten, auf die lange nicht zugegriffen wird, auslagern, wenn ihm das von Vorteil erscheint. Insofern macht auch bei viel RAM in einem System eine Swap-Partition weiterhin Sinn - wenngleich man diese dann eher verhaeltnismaessig klein anlegen kann. Ein Performance-Verlust bringt das im Prinzip nicht mit sich (wie gesagt, es werden Seiten ausgelagert, auf die schon lange nicht mehr zugegriffen wurde), oft ist eher das Gegenteil der Fall, da nun Daten eines aktuellen Prozesses ggf. besser gecacht werden koennen, usw. usw. Cheers, Th.
Thomas Hertweck, Freitag, 28. April 2006 19:45:
In der Tat kann der Kernel selbst bei sehr grosszuegig dimensioniertem RAM (das ist bei Dir ja gegeben) Speicherseiten, auf die lange nicht zugegriffen wird, auslagern, wenn ihm das von Vorteil erscheint. Insofern macht auch bei viel RAM in einem System eine Swap-Partition weiterhin Sinn - wenngleich man diese dann eher verhaeltnismaessig klein anlegen kann. Ein Performance-Verlust bringt das im Prinzip nicht mit sich (wie gesagt, es werden Seiten ausgelagert, auf die schon lange nicht mehr zugegriffen wurde), oft ist eher das Gegenteil der Fall, da nun Daten eines aktuellen Prozesses ggf. besser gecacht werden koennen, usw. usw.
OK, das war mir noch nicht so klar. Allerdings: wie erkenne ich denn, ob ein Rechner genügend RAM hat, oder ob er allmählich an die Grenzen kommt? Wenn sich der Kernel so und so einen Teil des Swap nimmt, um dorthin die kalten Seiten auszulagern, damit mehr Platz für die heißen Seiten ist, dann ist das swappen der Maschine ja kein Zeichen für Speicherknappheit. Bei einer meiner Maschinen sieht es gerade so aus: # free -m total used free shared buffers cached Mem: 503 489 14 0 0 121 -/+ buffers/cache: 368 135 Swap: 486 35 450 Ist jetzt der maßgebliche Wert die 121 MB cached gegenüber den nur 35 MB swap, sprich: der Kernel könnte leicht alles im RAM halten, und müßte dafür nur auf ein wenig cache verzichten? Oder hinkt diese Interpretation? -- Andre Tann
Hallo, Am Fri, 28 Apr 2006, Andre Tann schrieb:
Allerdings: wie erkenne ich denn, ob ein Rechner genügend RAM hat, oder ob er allmählich an die Grenzen kommt? Wenn sich der Kernel so und so einen Teil des Swap nimmt, um dorthin die kalten Seiten auszulagern, damit mehr Platz für die heißen Seiten ist, dann ist das swappen der Maschine ja kein Zeichen für Speicherknappheit.
Jep.
Bei einer meiner Maschinen sieht es gerade so aus:
# free -m total used free shared buffers cached Mem: 503 489 14 0 0 121 -/+ buffers/cache: 368 135 Swap: 486 35 450
Ist jetzt der maßgebliche Wert die 121 MB cached gegenüber den nur 35 MB swap, sprich: der Kernel könnte leicht alles im RAM halten, und müßte dafür nur auf ein wenig cache verzichten?
Ja. Beziehungsweise sollte man 'buffers + cached' in Relation zum verwendeten swap und zum RAM betrachten. Du koenntest folgende Rechnung machen: ( buffers + cached ) - used swap. Das Ergebnis sollte "gross genug" sein (50 - 100 MB?). Wenn du im Normalbetrieb vom swappen nix merkst ist der Wert "gross genug". Bei mir sieht's z.B. grad so aus: $ free -m total used free shared buffers cached Mem: 313 310 3 0 63 94 -/+ buffers/cache: 152 161 Swap: 1035 79 955 wobei ich ein paar Speicherfresser am laufen habe. Vom swappen merke ich i.d.R. nur was, wenn ich z.B. Mozilla lange minimiert hatte und das RAM derweil fuer anderes gebraucht wurde, da wandert mozilla dann praktisch komplett in die swaps und nach dem Wiederherstellen des Fensters braucht's ne Weile, bis die gerne 40 MB aus dem swap wieder da sind. Das ist mir dann aber auch egal :) BTW: dass ich 1 GB swap habe ist eher Zufall bei der Partitionierung (erst war's nur die eine 512MB Partition) aber auch Reserve. Wobei ich zur Not auch noch ne Swapdatei dazuhaenge[1]. $ cat /proc/swaps Filename Type Size Used Priority /dev/hdc2 partition 530136 40884 666 /dev/hdb2 partition 530136 40876 666 Am 'Used' sieht man auch schoen das SW-RAID 0 (? Striping eben) das aus den Swapbereichen gleicher Prioritaet gebildet wird. Und noch zum Speicher (bei gleicher Software): Mit 128 MB habe ich gemerkt, dass das zu wenig ist (haeufig etwas swappen, kaum buffers + cache), 196 MB waren "genug" und jetzt mit 320 MB habe ich (wie man sieht) "ordentlich" freies RAM fuer buffers+cache. Ist relativ typisch bei mir, dass ca. 50% des Speichers fuer buffers+cache verwendet werden. Apropos: was verwendest du denn an Speicherfressern, dass du ca. 400 MB RAM verbrauchst? Ist das alles KDE? (top und mit 'm' nach Speicher sortieren). -dnh, mit WindowMaker am Start *scnr* [1] ich habe neulich mal massiv Speicher gebraucht, da haben die ~1.3 GB nicht mehr gereicht. Seitdem habe ich ein 509k Apr 12 02:27 /swapfile.gz mit weiteren 512 MB vorbereitetem swap ;) Als .gz deswegen, weil ich dann nur noch ein 'gunzip /swapfile && swapon /swapfile' brauche. -- If you think sex is a pain in the arse, try a different position.
David Haller, Samstag, 29. April 2006 02:56:
Ja. Beziehungsweise sollte man 'buffers + cached' in Relation zum verwendeten swap und zum RAM betrachten. Du koenntest folgende Rechnung machen: ( buffers + cached ) - used swap. Das Ergebnis sollte "gross genug" sein (50 - 100 MB?). Wenn du im Normalbetrieb vom swappen nix merkst ist der Wert "gross genug".
OK, verstanden.
Apropos: was verwendest du denn an Speicherfressern, dass du ca. 400 MB RAM verbrauchst? Ist das alles KDE? (top und mit 'm' nach Speicher sortieren).
-dnh, mit WindowMaker am Start *scnr*
WindowMaker? KDE? Was ist das, irgendwas grafisches? Also auf meiner Maschine läuft kein X, wozu auch. Spaß beiseite, der Rechner, von dem vorgenanntes Speicherbild stammt, ist ein Server, und zwar Mail/Spamassasin/Amavis/Clamav/Mailman, dann NTP, DNS, DHCP, Apache, und darüber hinaus läuft darauf seit kurzem eine nette Groupware, die ziemlich speicherhungrig ist. Für jeden Client, der sich darauf verbindet, wird ein ca. 20 MB großer Prozeß gestartet. Daher werde ich diesem Rechner demnächst statt 512 MB 2GB verpassen. Dann sollte erst mal Ruhe sein, und ich hab viel Platz für Cache, das entlastet die Platte. -- Andre Tann
Hallo, Am Sat, 29 Apr 2006, Andre Tann schrieb:
David Haller, Samstag, 29. April 2006 02:56: [..]
Apropos: was verwendest du denn an Speicherfressern, dass du ca. 400 MB RAM verbrauchst? Ist das alles KDE? (top und mit 'm' nach Speicher sortieren).
-dnh, mit WindowMaker am Start *scnr*
WindowMaker? KDE? Was ist das, irgendwas grafisches?
Ja ;) [..]
Spaß beiseite, der Rechner, von dem vorgenanntes Speicherbild stammt, ist ein Server, und zwar Mail/Spamassasin/Amavis/Clamav/Mailman, dann NTP, DNS, DHCP,
SA, Amavis und Mailman sind AFAIK auch nicht gerade die bescheidensten was den Speicherbedarf angeht...
Apache, und darüber hinaus läuft darauf seit kurzem eine nette Groupware, die ziemlich speicherhungrig ist. Für jeden Client, der sich darauf verbindet, wird ein ca. 20 MB großer Prozeß gestartet. Daher werde ich diesem Rechner demnächst statt 512 MB 2GB verpassen. Dann sollte erst mal Ruhe sein, und ich hab viel Platz für Cache, das entlastet die Platte.
Jup. Ist z.B. auch bei nem Squid (fuer ne groessere Menge User) sinnvoll, bei dem dann ein guter Teil der Seiten in den Plattencache passen kann... Oder wenn ein httpd oder ftpd das wichtigste aus dem RAM liefern kann (ohne dass der daemon da selber was machen muss). Ist halt das schoene an Linux, das RAM wird immer sinnvoll verwendet. Aufpassen muss man halt, dass die Hardware auch korrekt mit soviel Speicher umgehen kann. Auf 32bit x86 bremst PAE u.U. doch ziemlich, so dass mit >= 4 GB das gesamte RAM langsamer ist als mit (ca.) <= 3.5 GB. -dnh -- Auch wieder richtig, aber zum bloed posten brauch ich kein Hirn. Ausserdem tipp ich schneller, als ich denke :). -- Klaus Muth
David Haller, Samstag, 29. April 2006 17:22:
Aufpassen muss man halt, dass die Hardware auch korrekt mit soviel Speicher umgehen kann. Auf 32bit x86 bremst PAE u.U. doch ziemlich, so dass mit >= 4 GB das gesamte RAM langsamer ist als mit (ca.) <= 3.5 GB.
Was ist denn PAE? Im übrigen dachte ich, daß der normale Kernel gar nicht mit mehr als 4 GB umgehen kann. -- Andre Tann
Hallo, Am Mon, 01 May 2006, Andre Tann schrieb:
David Haller, Samstag, 29. April 2006 17:22:
Aufpassen muss man halt, dass die Hardware auch korrekt mit soviel Speicher umgehen kann. Auf 32bit x86 bremst PAE u.U. doch ziemlich, so dass mit >= 4 GB das gesamte RAM langsamer ist als mit (ca.) <= 3.5 GB.
Was ist denn PAE?
Physical Address Extension. Siehe http://de.wikipedia.org/wiki/PAE
Im übrigen dachte ich, daß der normale Kernel gar nicht mit mehr als 4 GB umgehen kann.
Doch, klar, nur kompiliert SUSE die default Kernel nicht entsprechend. ==== /usr/src/linux/Documentation/Configure.help (Kernel 2.4.25) ==== High Memory support CONFIG_NOHIGHMEM Linux can use up to 64 Gigabytes of physical memory on x86 systems. However, the address space of 32-bit x86 processors is only 4 Gigabytes large. That means that, if you have a large amount of physical memory, not all of it can be "permanently mapped" by the kernel. The physical memory that's not permanently mapped is called "high memory". If you are compiling a kernel which will never run on a machine with more than 960 megabytes of total physical RAM, answer "off" here (default choice and suitable for most users). This will result in a "3GB/1GB" split: 3GB are mapped so that each process sees a 3GB virtual memory space and the remaining part of the 4GB virtual memory space is used by the kernel to permanently map as much physical memory as possible. If the machine has between 1 and 4 Gigabytes physical RAM, then answer "4GB" here. If more than 4 Gigabytes is used then answer "64GB" here. This selection turns Intel PAE (Physical Address Extension) mode on. PAE implements 3-level paging on IA32 processors. PAE is fully supported by Linux, PAE mode is implemented on all recent Intel processors (Pentium Pro and better). NOTE: If you say "64GB" here, then the kernel will not boot on CPUs that don't support PAE! The actual amount of total physical memory will either be auto detected or can be forced by using a kernel command line option such as "mem=256M". (Try "man bootparam" or see the documentation of your boot loader (grub, lilo or loadlin) about how to pass options to the kernel at boot time.) If unsure, say "off". 4GB CONFIG_HIGHMEM4G Select this if you have a 32-bit processor and between 1 and 4 gigabytes of physical RAM. 64GB CONFIG_HIGHMEM64G Select this if you have a 32-bit processor and more than 4 gigabytes of physical RAM. ==== Und /proc/cpuinfo bei mir: vendor_id : AuthenticAMD cpu family : 6 model : 1 model name : AMD-K7(tm) Processor stepping : 2 cpu MHz : 499.040 cache size : 512 KB [..] flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx syscall mmxext 3dnowext 3dnow bogomips : 996.14 Wie du siehst taucht selbst auf diesem inzwischen alten Prozessor von 1999 (der erste und langsamste AMD Athlon) das 'pae' flag auf. Und das MoBo kann eh nur 768 MB. HTH, -dnh -- So Linus, what are we doing tonight? The same thing we do every night Tux. Try to take over the world!
On Fri, 28 Apr 2006 18:45:43 +0100 Thomas Hertweck <Thomas.Hertweck@web.de> wrote: Moin,
In der Tat kann der Kernel selbst bei sehr grosszuegig dimensioniertem RAM (das ist bei Dir ja gegeben) Speicherseiten, auf die lange nicht zugegriffen wird, auslagern, wenn ihm das von Vorteil erscheint. Insofern macht auch bei viel RAM in einem System eine Swap-Partition weiterhin Sinn - wenngleich man diese dann eher verhaeltnismaessig klein anlegen kann. Ein Performance-Verlust bringt das im Prinzip nicht mit sich (wie gesagt, es werden Seiten ausgelagert, auf die schon lange nicht mehr zugegriffen wurde), oft ist eher das Gegenteil der Fall, da nun Daten eines aktuellen Prozesses ggf. besser gecacht werden koennen, usw. usw.
Dieses Verhalten kann man aber seit dem 2.6er Kernel selber beeinflussen. Googelt mal nach "vm_swappiness". Nur son kleiner Tipp am Rande. ;) Sonnige Grüsse, Timo Eckert
participants (7)
-
Andre Tann -
David Haller -
Martin Hochreiter -
Ralf Prengel -
Thomas Hertweck -
Timo Eckert -
Werner Flamme