Hi!
Es geht um das MySQL Debian Sarge. Und zwar will ich: * den Daemon im Vordergrund halten * die Anzahl der Threads bzw. Prozesse begrenzen.
Weiß da jemand mehr?
Danke!
MfG Sebastian
am 18.03.2005, um 1:22:30 +0100 mailte Sebastian Hegler folgendes:
Hi!
Es geht um das MySQL Debian Sarge. Und zwar will ich:
- den Daemon im Vordergrund halten
wie meinen? Wie startest Du den MySQL-Server, per init-Script oder via (x)inetd?
- die Anzahl der Threads bzw. Prozesse begrenzen.
suchst Du max_connections ?
Weiß da jemand mehr?
Schon mal in der Doku geschaut? Ich nutze kein MySQL, aber diese Parameter fand ich mit Google quasi in Null-Komma-Nix.
Andreas
Andreas Kretschmer wrote:
wie meinen? Wie startest Du den MySQL-Server, per init-Script oder via (x)inetd?
daemontools ("http://cr.yp.to/daemontools.html") ist das Ziel, da darf das Ding sich nicht in den Hintergrund drücken, indem es std(in|out|err) mit /dev/null dup2't.
- die Anzahl der Threads bzw. Prozesse begrenzen.
suchst Du max_connections ?
Nein, die Anzahl der Prozesse oder Threads. Hat nix mit max_connections zu tun.
Schon mal in der Doku geschaut?
Stundenlang. Sonst würd ich hier nicht fragen.
MfG Sebastian
On Friday 18 March 2005 12:54, Sebastian Hegler wrote:
Andreas Kretschmer wrote:
wie meinen? Wie startest Du den MySQL-Server, per init-Script oder via (x)inetd?
daemontools ("http://cr.yp.to/daemontools.html") ist das Ziel, da darf das Ding sich nicht in den Hintergrund drücken, indem es std(in|out|err) mit /dev/null dup2't.
Um ein paar Sachen klarzustellen:
*ein Daemon ersetzt stdin/out/err nicht durch /dev/null, sondern schliesst sie ganz einfach *danach macht er ein fork, um sein Controlling-Terminal zu verlieren (nicht um den Admin zu ärgern) *er dup2't auch nicht wild durch die Gegend *wenn er nett ist macht er auch chmod("/"), damit er einem umount nicht im Weg ist
MySQL in den non-daemon-mode zu versetzen geht scheinbar nicht - was ich gut verstehen kann, es ist schliesslich ein Datenbankserver, nicht irgendein lausiger IRC-Daemon dem es nix ausmacht vom Terminal gekillt zu werden.
Die Bemerkungen in der FAQ von daemontools klingen sehr zweifelhaft. Da hat jemand ganz eindeutig die Konzepte von Unix nicht verstanden. Ich würde Dir stärkstens davon abraten dieses Teil zu benutzen.
- die Anzahl der Threads bzw. Prozesse begrenzen.
suchst Du max_connections ?
Nein, die Anzahl der Prozesse oder Threads. Hat nix mit max_connections zu tun.
Zumindest auf einen Thread kannst Du begrenzen: --one-thread
Aber wozu der Aufwand? So ein Thread frisst kaum Resourcen, wir sind hier schliesslich nicht unter Windoofs.
Schon mal in der Doku geschaut?
Stundenlang. Sonst würd ich hier nicht fragen.
Mehr als eine Seite angestarrt? ;-)
Was willst Du eigentlich erreichen? Willst Du nur spielen oder hat das irgendeinen echten Zweck?
Konrad
Konrad Rosenbaum wrote:
Um ein paar Sachen klarzustellen:
[snip] Danke für die Klarstellungen.
Die Bemerkungen in der FAQ von daemontools klingen sehr zweifelhaft. Da hat jemand ganz eindeutig die Konzepte von Unix nicht verstanden.
Bitte keine philosophischen Debatten. "Keine Angst! Ich weiß, was ich tue." (Zitat Sledge Hammer)
Ich würde Dir stärkstens davon abraten dieses Teil zu benutzen.
Indiskutabel, wenn Du nen lausigen rootserver hast, bei dem ständig irgendwelche Sachen wegen "kein Speicher mehr" gekillt werden. Die FAQs haben allerdings an einer Stelle recht: wenn der Dienst wegen Speicherende spurlos abraucht, kommt er nicht wieder hoch, außer mit diesem Stück Software. Ziel ist es somit, die Dienste 1.) verfügbar zu halten, und 2) Speicherlast runterzukriegen.
Zumindest auf einen Thread kannst Du begrenzen: --one-thread
Nicht bei dem Debian Standard-Build. Also werd ich nach lautem Fluchen wohl doch den gcc bemühen müssen...
Aber wozu der Aufwand? So ein Thread frisst kaum Resourcen, wir sind hier schliesslich nicht unter Windoofs.
Siehe oben.
Mehr als eine Seite angestarrt? ;-)
Laß es zwei sein ;)
MfG Sebastian
Am Freitag, 18. März 2005 20:22 schrieb Sebastian Hegler:
Indiskutabel, wenn Du nen lausigen rootserver hast, bei dem ständig irgendwelche Sachen wegen "kein Speicher mehr" gekillt werden. Die FAQs haben allerdings an einer Stelle recht: wenn der Dienst wegen Speicherende spurlos abraucht, kommt er nicht wieder hoch, außer mit diesem Stück Software. Ziel ist es somit, die Dienste 1.) verfügbar zu halten, und 2) Speicherlast runterzukriegen.
Du meinst, falls eine TCP-Anfrage auf einem Port kommt, und der MySQL ist tot, diesen dann zu starten und dann die Anfrage transparent weiterzuleiten?
Das Problem hat man ja bei Live-CDs, wo sich der JAP zu Beginn noch nicht verbinden kann, weil das Netzwerk noch nicht konfiguriert ist. Lösung: Proxy in den Browsern auf Port 10000 einrichten, diese dann über die Weiterleitung auf den (nur lokal zugreifbaren) JAP-Port schicken.
Wir hatten das Thema morebalance zwar grad erst, aber weil's so schön ist, hier nochmal - für MySQL sähe das Szenario so aus: morebalance -i "10000 use localhost as mysql launching /usr/sbin/mysqld"
Dann kann über Port 10000 drauf zugegriffen werden (oder 10000:local, falls nur für PHP etc. benötigt). Ist MySQL mal tot, wird er neu gestartet.
Josef
On Friday 18 March 2005 20:22, Sebastian Hegler wrote:
Konrad Rosenbaum wrote:
Ich würde Dir stärkstens davon abraten dieses Teil zu benutzen.
Indiskutabel, wenn Du nen lausigen rootserver hast, bei dem ständig irgendwelche Sachen wegen "kein Speicher mehr" gekillt werden.
Korrekte Gegenmaßnahmen wären:
1. Swap einrichten 2. beim Provider nachfragen, was ein Speicherupgrade kostet 3. Provider wechseln
Mir ist das auf meinem Rootserver jedenfalls noch nie passiert: 256MB Ram, ca. 700MB Swap, Swap wird kaum benutzt (nur ca. 10MB nach mehreren Monaten Uptime).
Konrad
Am Freitag, den 18.03.2005, 19:38 +0100 schrieb Konrad Rosenbaum:
daemontools ("http://cr.yp.to/daemontools.html") ist das Ziel, da darf das Ding sich nicht in den Hintergrund drücken, indem es std(in|out|err) mit /dev/null dup2't.
Um ein paar Sachen klarzustellen:
[...]
Die Bemerkungen in der FAQ von daemontools klingen sehr zweifelhaft. Da hat jemand ganz eindeutig die Konzepte von Unix nicht verstanden. Ich würde Dir stärkstens davon abraten dieses Teil zu benutzen.
Die oben gequotete URL klingt nach DJB. Er will die Konzepte nicht verstehen. Die Frage ob das gut oder schlecht ist, ist heute quasi schon religöser Natur...
Eric
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Eric Schaefer -
Josef Spillner -
Konrad Rosenbaum -
Sebastian Hegler