MySQL, ein bischchen php & ärger...

Einleitend: Ich mag beides (im Subject erwähnte) nicht besonders -
und bin möglicherweise etwas naiv an das ganze rangegangen. Es ist
auch gut möglich, dass ich in den letzten 2 Stunden beim googlen
massiv die falschen Begriffe verwendet habe - also bitte um
Verzeihung falls das a) "altbekannt" ist und b) total einfach zu
lösen ...

Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
nicht mehr wirklich total super.

Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
Damit die webuser nix umstellen muessen, bleiben alle datenbanken
einfach auf dem einen sql server.

Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
werden schlank gegen den Datenbank-Host abgebogen.

ABER: php versucht krampfhaft den unix domain socket zu verwenden,
wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
drinnen steht (WTF?!)). Ich mag jetzt aus verständlichen Gründen
nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
und "localhost" durch "127.0.0.1" ersetzen ...

Also wie kriege ich auf den socket auf den Webservern? gibt es sowas
wie einen "proxy" dafür? Ich fasse auch ein Master/Slave ins Auge -
jedoch kann man da "mischen" - also master als mysql4 und die slaves
mysql5? Ich sehe auch keinen enormen gewinn darin irgendwas zu
replizieren (am besten überhaupt nix) - ich will nur die queries
durchgereicht haben. Wenn ich also *keine* datenbanken bei den
replicate-do-db= einträgen angebe - gibts die an den slaves dann
trozdem?

Oder Übersehe ich hier noch eine ganz einfache und naheliegende
Möglichkeit? Am allerliebsten wäre mir ein "promitiv-proxy", der
einfach nur /tmp/mysql.sock abgreift uns das am Datenbank-host
ebendort wieder einwirft? Gibts sowas fertig oder muss man das
selbst machen?

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger ...

Hallo,

Clemens Zauner wrote:
> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
> drinnen steht (WTF?!)). Ich mag jetzt aus verständlichen Gründen

Ist immer so.

> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
> und "localhost" durch "127.0.0.1" ersetzen ...

man sed :]

Vielleicht hilft das weiter?

| mysqli.default_port string
|
| The default TCP port number to use when connecting to the database
| server if no other port is specified. If no default is specified, the
port will
| be obtained from the MYSQL_TCP_PORT environment variable, the
| mysql-tcp entry in /etc/services or the compile-time MYSQL_PORT constant,
| in that order. Win32 will only use the MYSQL_PORT constant.

Ich vermute (!), dass du per
| php_admin_value mysqli.default_port "127.0.0.1:3301"
(oder was auch immer der Port ist) in der Lage sein solltest,
standardmäßig eine TCP-Verbindung statt eines Unix-Sockets zu erzwingen.
Wie gesagt, nur eine Vermutung, hier ist wohl Trial-and-Error angesagt :)

Viele Grüße,
Michael

Re: MySQL, ein bischchen php & ärger...

Clemens Zauner wrote:
>
> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
> nicht mehr wirklich total super.

Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
problems mit der gebotenen Sorgfalt erfolgt ist.

> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).

Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.

> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
> einfach auf dem einen sql server.

Diesen Satz verstehe ich nicht. Aber egal.

> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
> werden schlank gegen den Datenbank-Host abgebogen.

Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
irgendwie "umbiegen"?

> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
> drinnen steht (WTF?!)).

Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
auf Betriebssystemen, die keine UNIX-Sockets haben.

> Ich mag jetzt aus verständlichen Gründen
> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
> und "localhost" durch "127.0.0.1" ersetzen ...

M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
daß alle PHP-Applikationen dirty hacks sein müßten.

Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
weise die Applikationen, für die das einfach geht. Dem Rest kannst du
schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
schlechter Performance leben müssen.

> Also wie kriege ich auf den socket auf den Webservern? gibt es sowas
> wie einen "proxy" dafür?

Es spricht nichts dagegen, einen Proxy zu machen, der zwischen einem
UNIX-Socket und einem entfernten INET-Socket vermittelt. Ich kenne
kein solches Programm (aber vielleicht Google). Ich halte das auch für
eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.


XL

Re: MySQL, ein bischchen php & ärger...

Michael Ziegler wrote:
> Clemens Zauner wrote:
>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>> drinnen steht (WTF?!)). Ich mag jetzt aus verständlichen Gründen
>
> Ist immer so.

Wie soll ich sagen ... "brilliant". Ehrlich.

>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>> und "localhost" durch "127.0.0.1" ersetzen ...
>
> man sed :]

Hnnng. ich vermute, das macht mehr kaputt... Denn einfach "localhost"
durch 127.0.0.1 zu ersetzen hat sicher in mindestens einem Fall
irgendeinen nebeneffekt (weils in dem Fall z.B. gerade nix mit
mysql zu tun hat).

> Vielleicht hilft das weiter?
>
> | mysqli.default_port string

Ummm die verwenden fast alle anscheinend nicht mysqli sondern das normale
mysql, zum beispiel mit aufrufen ala "$this->db = mysql_connect($h,$u,$p);"
sonst müsste es ja "mysqli_connect(...);" sein, oder?

> Ich vermute (!), dass du per
> | php_admin_value mysqli.default_port "127.0.0.1:3301"

Ich habs mit mysqli.default_port und mysql.default_port versucht; vergeblich,
auch verschiedene values (also ohne host-part, ...) - Auswirkungen null.

> (oder was auch immer der Port ist) in der Lage sein solltest,
> standardmäßig eine TCP-Verbindung statt eines Unix-Sockets zu erzwingen.

Ja - *genau* das möchte ich. Es wäre ja schon viel gewonnen, wenn
die "intelligenz" von dem zeug so weitgehend wäre bei einem connect
nach "localhost" bei offensichtlicher Abwesenheit des Sockets
dann doch eine TCP-Session zu "probieren".

> Wie gesagt, nur eine Vermutung, hier ist wohl Trial-and-Error angesagt :)

Ich hatte schon einiges an "Trial" und genausoviel "Error". Hmmpf.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger...

Clemens Zauner wrote:
> Michael Ziegler wrote:
>> Clemens Zauner wrote:
>>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>>> drinnen steht (WTF?!)). Ich mag jetzt aus verständlichen Gründen
>>
>> Ist immer so.
>
> Wie soll ich sagen ... "brilliant". Ehrlich.

http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.ht ml

"MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, ...

mysql_real_connect() attempts to establish a connection to a MySQL
database engine running on host.
....

The value of host may be either a hostname or an IP address. If host
is NULL or the string "localhost", a connection to the local host is
assumed. For Windows, the client connects using a shared-memory
connection, if the server has shared-memory connections enabled.
Otherwise, TCP/IP is used. For Unix, the client connects using a Unix
socket file. For local connections, you can also influence the type of
connection to use with the MYSQL_OPT_PROTOCOL or MYSQL_OPT_NAMED_PIPE
options to mysql_options(). The type of connection must be supported by
the server. For a host value of "." on Windows, the client connects
using a named pipe, if the server has named-pipe connections enabled.
If named-pipe connections are not enabled, an error occurs."


http://dev.mysql.com/doc/refman/5.0/en/mysql-options.html

"int mysql_options(MYSQL *mysql, enum mysql_option option,
const char *arg)

Can be used to set extra connect options and affect behavior for a
connection.
....

MYSQL_OPT_PROTOCOL (argument type: unsigned int *)

Type of protocol to use. Should be one of the enum values of
mysql_protocol_type defined in mysql.h."


mysql.h:

enum mysql_protocol_type
{
MYSQL_PROTOCOL_DEFAULT, MYSQL_PROTOCOL_TCP, MYSQL_PROTOCOL_SOCKET,
MYSQL_PROTOCOL_PIPE, MYSQL_PROTOCOL_MEMORY
};


-> man *kann* das hacken - wenn man es kann ;-)


XL

Re: MySQL, ein bischchen php & ärger...

Axel Schwenke wrote:
> The value of host may be either a hostname or an IP address. If host
> is NULL or the string "localhost", a connection to the local host is
> assumed. For Windows, the client connects using a shared-memory

Nutzt nix, das hatte ich recht rasch rausgefunden. Ich finds trotzdem
*dämlich*.

> -> man *kann* das hacken - wenn man es kann ;-)

Das ist alles ganz schon und gut; aber umschreiben ist nicht. das Teil
sollte wartbar bleiben. Immerhin haben ich die letzten 3 Monate damit
verbracht solche "loesungen" wieder zu entfernen.

Ist die Software wirklich so selbst herrlich, das nicht als tunable
zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
zur Suche, vermute aber immer mehr eine eine solche ganz woanders.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger...

Axel Schwenke wrote:
>> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
>> nicht mehr wirklich total super.
>
> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
> problems mit der gebotenen Sorgfalt erfolgt ist.

Das sei dir unbenommen.

>> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
>
> Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
> einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.

Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
Architektur hat gewisse Grenzen.

>> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
>> einfach auf dem einen sql server.
>
> Diesen Satz verstehe ich nicht. Aber egal.

Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
gar nichts anzugehen. Das skaliert. Als allererstes liegt es mir mal
am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
nicht mehr das, was ich unter "wartbar" verstehe).
Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
ist total hypsch redundant. Und wenn die Leistung knapp wird,
schnallt man halt noch mehr http-frontends dran.

Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
aber Essig mit dem Ansatz "ein Datenbankhost".
Nämlich genau wegen dem default-verhalten bei "localhost".

>> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
>> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
>> werden schlank gegen den Datenbank-Host abgebogen.
>
> Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
> glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
> irgendwie "umbiegen"?

Ja, klar. Geht die php-Dinger ja quasi genau gar nix an wo die Datenbank
läuft.

>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>> drinnen steht (WTF?!)).
>
> Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
> auf Betriebssystemen, die keine UNIX-Sockets haben.

Hmmm. Das eröffnet jetzt möglichkeiten. Mal die compile-flags durchsehen,
eventuell gibts sowas wie --has-no-domain-sockets.

>> Ich mag jetzt aus verständlichen Gründen
>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>> und "localhost" durch "127.0.0.1" ersetzen ...
>
> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".

Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
Letztere haben so den Vorteil dass sie leicht austauschbar sind.
Und quasi beliebig vervielfältigt werden können.
Backup/Restore ist in so einer Umgebung ein leichtes. Und Mission-
Critical sind nur mehr File- und Datenbankstorage, sowie der balancer
vorne.

> Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
> Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
> 95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
> etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
> daß alle PHP-Applikationen dirty hacks sein müßten.

Ja. *allerdings* lauft auf dem ding nicht eine App sondern ein paar
hundert. Ich bin mir sicher, dass die Inhaber der jeweiligen Web-
präsenzen nicht mehr im geringsten wissen, wer ihnen das vor Jahren
gecoded hat.

> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
> schlechter Performance leben müssen.

Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
extrem unaufgeräumt und nervig in der Maintainance.

> eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
> Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.

Glaube mir, ich starre das Drama schon einige Zeit an. Bisher hatte
ich zum Glück immer drängendere Baustellen (Mail, DNS, ..) gefunden.
Aber so langsam würde ich die Sache mit den Webservern angehen.
Eigentlich hatte ich mir das für Mai vorgenommen. Und abgesehen
von dem nervigen fall-back aufs Socket täte das ja ganz hypsch
funktionieren (es gibt Leute ohne php/mysql kombinationen).

Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
(wenn kein socket da, dann probiere doch mal TCP ...).

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger ...

Eine (zugegebenermassen nicht schöne) Lösung wäre einfach ein ssh Tunnel.

Du brauchst auf dem DB-Server einen SSH-Server und möglichst einen
dedzierten Benutzer (z.B. "dbtunnel").

Anschließend startest Du auf dem Webserver

ssh -Nfg -i -L3306:127.0.0.1:3306 dbtunnel@datenbankserver

Anschließend verlangt der Client nach dem Passwort von dbtunnel. Eine
Alternative wäre der Login via OpenSSH Schlüssel.

Damit öffnest Du einen Tunnel, der auf 127.0.0.1 alle Anfragen auf Port
3306 entgegennimmt, an den Datenbankserver weiterleitet und dort an den
Port 3306 weitergibt.

Der Charme dieser Lösung ist, daß das Forwarding für MySQL vollkommen
transparent ist, und du keinerlei Anpassungen an den Benutzerrechten des
MySQL Servers vornehmen musst. Es muß dort noch nicht einmal der Port
3306 offen sein, Port 22 reicht.

Du solltest nur die Timeout-Optionen des SSH Servers (auf dem DB-Host)
und des SSH Clients (auf dem Web-Host) noch etwas tunen, daß hier die
Verbindung nicht regelmäßig abgebrochen wird.



Grüße,


Alex



Clemens Zauner schrieb:
> Axel Schwenke wrote:
>>> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
>>> nicht mehr wirklich total super.
>> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
>> problems mit der gebotenen Sorgfalt erfolgt ist.
>
> Das sei dir unbenommen.
>
>>> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
>> Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
>> einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.
>
> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
> Architektur hat gewisse Grenzen.
>
>>> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
>>> einfach auf dem einen sql server.
>> Diesen Satz verstehe ich nicht. Aber egal.
>
> Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
> Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
> gar nichts anzugehen. Das skaliert. Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).
> Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
> ist total hypsch redundant. Und wenn die Leistung knapp wird,
> schnallt man halt noch mehr http-frontends dran.
>
> Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
> auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
> aber Essig mit dem Ansatz "ein Datenbankhost".
> Nämlich genau wegen dem default-verhalten bei "localhost".
>
>>> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
>>> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
>>> werden schlank gegen den Datenbank-Host abgebogen.
>> Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
>> glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
>> irgendwie "umbiegen"?
>
> Ja, klar. Geht die php-Dinger ja quasi genau gar nix an wo die Datenbank
> läuft.
>
>>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>>> drinnen steht (WTF?!)).
>> Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
>> auf Betriebssystemen, die keine UNIX-Sockets haben.
>
> Hmmm. Das eröffnet jetzt möglichkeiten. Mal die compile-flags durchsehen,
> eventuell gibts sowas wie --has-no-domain-sockets.
>
>>> Ich mag jetzt aus verständlichen Gründen
>>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>>> und "localhost" durch "127.0.0.1" ersetzen ...
>> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
>
> Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
> entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
> Letztere haben so den Vorteil dass sie leicht austauschbar sind.
> Und quasi beliebig vervielfältigt werden können.
> Backup/Restore ist in so einer Umgebung ein leichtes. Und Mission-
> Critical sind nur mehr File- und Datenbankstorage, sowie der balancer
> vorne.
>
>> Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
>> Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
>> 95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
>> etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
>> daß alle PHP-Applikationen dirty hacks sein müßten.
>
> Ja. *allerdings* lauft auf dem ding nicht eine App sondern ein paar
> hundert. Ich bin mir sicher, dass die Inhaber der jeweiligen Web-
> präsenzen nicht mehr im geringsten wissen, wer ihnen das vor Jahren
> gecoded hat.
>
>> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
>> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
>> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
>> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
>> schlechter Performance leben müssen.
>
> Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
> extrem unaufgeräumt und nervig in der Maintainance.
>
>> eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
>> Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.
>
> Glaube mir, ich starre das Drama schon einige Zeit an. Bisher hatte
> ich zum Glück immer drängendere Baustellen (Mail, DNS, ..) gefunden.
> Aber so langsam würde ich die Sache mit den Webservern angehen.
> Eigentlich hatte ich mir das für Mai vorgenommen. Und abgesehen
> von dem nervigen fall-back aufs Socket täte das ja ganz hypsch
> funktionieren (es gibt Leute ohne php/mysql kombinationen).
>
> Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
> nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
> (wenn kein socket da, dann probiere doch mal TCP ...).
>
> cu
> Clemens.

Re: MySQL, ein bischchen php & ärger ...

Eine (zugegebenermassen nicht schöne) Lösung wäre einfach ein ssh Tunnel.

Du brauchst auf dem DB-Server einen SSH-Server und möglichst einen
dedzierten Benutzer (z.B. "dbtunnel").

Anschließend startest Du auf dem Webserver

ssh -Nfg -L3306:127.0.0.1:3306 dbtunnel@datenbankserver

Anschließend verlangt der Client nach dem Passwort von dbtunnel. Eine
Alternative wäre der Login via OpenSSH Schlüssel.

Damit öffnest Du einen Tunnel, der auf 127.0.0.1 alle Anfragen auf Port
3306 entgegennimmt, an den Datenbankserver weiterleitet und dort an den
Port 3306 weitergibt.

Der Charme dieser Lösung ist, daß das Forwarding für MySQL vollkommen
transparent ist, und du keinerlei Anpassungen an den Benutzerrechten des
MySQL Servers vornehmen musst. Es muß dort noch nicht einmal der Port
3306 offen sein, Port 22 reicht.

Du solltest nur die Timeout-Optionen des SSH Servers (auf dem DB-Host)
und des SSH Clients (auf dem Web-Host) noch etwas tunen, daß hier die
Verbindung nicht regelmäßig abgebrochen wird.



Grüße,


Alex



Clemens Zauner schrieb:
> Axel Schwenke wrote:
>>> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
>>> nicht mehr wirklich total super.
>> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
>> problems mit der gebotenen Sorgfalt erfolgt ist.
>
> Das sei dir unbenommen.
>
>>> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
>> Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
>> einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.
>
> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
> Architektur hat gewisse Grenzen.
>
>>> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
>>> einfach auf dem einen sql server.
>> Diesen Satz verstehe ich nicht. Aber egal.
>
> Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
> Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
> gar nichts anzugehen. Das skaliert. Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).
> Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
> ist total hypsch redundant. Und wenn die Leistung knapp wird,
schnallt man halt noch mehr http-frontends dran.
>
> Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
> auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
aber Essig mit dem Ansatz "ein Datenbankhost".
> Nämlich genau wegen dem default-verhalten bei "localhost".
>>> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
>>> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
>>> werden schlank gegen den Datenbank-Host abgebogen.
>> Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
>> glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
>> irgendwie "umbiegen"?
>
> Ja, klar. Geht die php-Dinger ja quasi genau gar nix an wo die Datenbank
> läuft.
>
>>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>>> drinnen steht (WTF?!)).
>> Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
>> auf Betriebssystemen, die keine UNIX-Sockets haben.
>
> Hmmm. Das eröffnet jetzt möglichkeiten. Mal die compile-flags durchsehen,
> eventuell gibts sowas wie --has-no-domain-sockets.
>
>>> Ich mag jetzt aus verständlichen Gründen
>>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>>> und "localhost" durch "127.0.0.1" ersetzen ...
>> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
>
> Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
> entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
> Letztere haben so den Vorteil dass sie leicht austauschbar sind.
> Und quasi beliebig vervielfältigt werden können.
> Backup/Restore ist in so einer Umgebung ein leichtes. Und Mission-
> Critical sind nur mehr File- und Datenbankstorage, sowie der balancer
> vorne.
>> Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
>> Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
>> 95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
>> etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
>> daß alle PHP-Applikationen dirty hacks sein müßten.
>
> Ja. *allerdings* lauft auf dem ding nicht eine App sondern ein paar
hundert. Ich bin mir sicher, dass die Inhaber der jeweiligen Web-
> präsenzen nicht mehr im geringsten wissen, wer ihnen das vor Jahren
> gecoded hat.
>
>> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
>> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
>> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
>> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
>> schlechter Performance leben müssen.
>
> Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
> extrem unaufgeräumt und nervig in der Maintainance.
>
>> eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
>> Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.
>
> Glaube mir, ich starre das Drama schon einige Zeit an. Bisher hatte
> ich zum Glück immer drängendere Baustellen (Mail, DNS, ..) gefunden.
> Aber so langsam würde ich die Sache mit den Webservern angehen.
> Eigentlich hatte ich mir das für Mai vorgenommen. Und abgesehen
> von dem nervigen fall-back aufs Socket täte das ja ganz hypsch
> funktionieren (es gibt Leute ohne php/mysql kombinationen).
>
> Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
> nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
> (wenn kein socket da, dann probiere doch mal TCP ...).
>
> cu
> Clemens.


Clemens Zauner schrieb:
> Axel Schwenke wrote:
>>> Zur Zeit: Ein server mit mysql-4 und php-4 drauf. Die Performance ist
>>> nicht mehr wirklich total super.
>> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
>> problems mit der gebotenen Sorgfalt erfolgt ist.
>
> Das sei dir unbenommen.
>
>>> Idee: man macht einmal sql, und n mal Webserver (klingt einfach).
>> Und warum sollte *das* dein Problem lösen? Vielleicht hätte es ja
>> einfach schon gereicht, dem Server ein bisschen RAM zu spendieren.
>
> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
> Architektur hat gewisse Grenzen.
>
>>> Damit die webuser nix umstellen muessen, bleiben alle datenbanken
>>> einfach auf dem einen sql server.
>> Diesen Satz verstehe ich nicht. Aber egal.
>
> Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
> Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
> gar nichts anzugehen. Das skaliert. Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).
> Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
> ist total hypsch redundant. Und wenn die Leistung knapp wird,
> schnallt man halt noch mehr http-frontends dran.
>
> Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
> auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
> aber Essig mit dem Ansatz "ein Datenbankhost".
> Nämlich genau wegen dem default-verhalten bei "localhost".
>
>>> Also 2 Webserver, einer mit php4, der andere mit php5 .. schaut
>>> alles irgendwie gut aus. Alle TCP-Connects gegen 127.0.0.1:3306
>>> werden schlank gegen den Datenbank-Host abgebogen.
>> Ich hoffe ich verstehe das falsch - du läßt alle PHP-Skripte weiterhin
>> glauben, ihr MySQL laufe lokal und willst die Netzwerkkommunikation
>> irgendwie "umbiegen"?
>
> Ja, klar. Geht die php-Dinger ja quasi genau gar nix an wo die Datenbank
> läuft.
>
>>> ABER: php versucht krampfhaft den unix domain socket zu verwenden,
>>> wenn der "host" "localhost" ist (dem ist nicht so, wenn da "127.0.0.1"
>>> drinnen steht (WTF?!)).
>> Das ist das dokumentierte Verhalten der MySQL-Client-Library. Außer
>> auf Betriebssystemen, die keine UNIX-Sockets haben.
>
> Hmmm. Das eröffnet jetzt möglichkeiten. Mal die compile-flags durchsehen,
> eventuell gibts sowas wie --has-no-domain-sockets.
>
>>> Ich mag jetzt aus verständlichen Gründen
>>> nicht ein paar 100 php-projekte von leuten auf den servern durchgehen
>>> und "localhost" durch "127.0.0.1" ersetzen ...
>> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
>
> Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
> entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
> Letztere haben so den Vorteil dass sie leicht austauschbar sind.
> Und quasi beliebig vervielfältigt werden können.
> Backup/Restore ist in so einer Umgebung ein leichtes. Und Mission-
> Critical sind nur mehr File- und Datenbankstorage, sowie der balancer
> vorne.
>
>> Eine vernünftige LAMP-Applikation hat genau eine Stelle, wo man den
>> Namen (oder die IP-Adresse) des MySQL-Server konfiguriert. Keine Frage,
>> 95% aller PHP-Applikationen sind nicht so sauber (das hat PHP auch den
>> etwas zweifelhaften Ruf eingebracht) - aber es ist kein Naturgesetz,
>> daß alle PHP-Applikationen dirty hacks sein müßten.
>
> Ja. *allerdings* lauft auf dem ding nicht eine App sondern ein paar
> hundert. Ich bin mir sicher, dass die Inhaber der jeweiligen Web-
> präsenzen nicht mehr im geringsten wissen, wer ihnen das vor Jahren
> gecoded hat.
>
>> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
>> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
>> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
>> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
>> schlechter Performance leben müssen.
>
> Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
> extrem unaufgeräumt und nervig in der Maintainance.
>
>> eine schlechte Lösung. Das Hauptproblem ist IMHO, daß du über bestimmte
>> Lösungen nachdenkst, ohne überhaupt eine Ursache zu kennen.
>
> Glaube mir, ich starre das Drama schon einige Zeit an. Bisher hatte
> ich zum Glück immer drängendere Baustellen (Mail, DNS, ..) gefunden.
> Aber so langsam würde ich die Sache mit den Webservern angehen.
> Eigentlich hatte ich mir das für Mai vorgenommen. Und abgesehen
> von dem nervigen fall-back aufs Socket täte das ja ganz hypsch
> funktionieren (es gibt Leute ohne php/mysql kombinationen).
>
> Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
> nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
> (wenn kein socket da, dann probiere doch mal TCP ...).
>
> cu
> Clemens.

Re: MySQL, ein bischchen php & ärger ...

On 7 Mai, 23:58, Clemens Zauner wrote:
> Nutzt nix, das hatte ich recht rasch rausgefunden. Ich finds trotzdem
> *dämlich*.

"It's not a bug ... it's a feature" ... nachdem MySQL seine Wurzeln
bei mSQL (Minerva bzw. Mini-SQL) hat und es eigentlich von dort her
stammt, ist das Übel schon *sehr* alt ;-) Schon damals wurde das so
gehandhabt, dass "localhost" auf Unix-Sockets geht und nicht via TCP/
IP ... mit dem Murks unter Windows habe ich mich schon ausgiebig
auseinander gesetzt: Es soll funktionieren, aber einer von beiden hat
geschlampt ... entweder MySQL mit ihrem Windows-Port oder das PHP-Team
- mir ist es noch nicht gelungen, unter Windows statt per TCP/IP über
was anderes zu gehen ...

Egal: Auch wenn es eine Schweinearbeit ist - letzten Endes macht es
durchaus Sinn, die *ganzen* PHP-Skripte durchzuforsten und die Zugänge
zu MySQL auf einen Nenner (sprich: php.ini) zu bringen! Es ist höchst
grausam und gefährlich, solche Connections im PHP-Skript zu
definieren ... welche Datenbank (auf einem Server) verwendet werden
soll, dann kann angehen, aber User/Passwort/Host/Port haben dort
nichts verloren.

Insofern: Mach' Dir einmal die Arbeit, aber dann hast Du's sauber! Und
dann brauchst Du keine Tunnel-Bastellösungen mehr ...

> Ist die Software wirklich so selbst herrlich, das nicht als tunable
> zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
> zur Suche, vermute aber immer mehr eine eine solche ganz woanders.

Du schreibst was von "php" - was willst Du dann mit "my.cnf"? Das, was
Du suchst, ist in der "php.ini" ...

Gruß, Dirk

Re: MySQL, ein bischchen php & ärger...

Clemens Zauner!

> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
> Architektur hat gewisse Grenzen.

64 GiB ab Pentium. Sollte reichen. Wenn man freilich am Board gespart
hat...


Gruß
Daniel

Re: MySQL, ein bischchen php & ärger ...

On 8 Mai, 08:46, Daniel Fischer wrote:
>> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
>> Architektur hat gewisse Grenzen.
> 64 GiB ab Pentium. Sollte reichen. Wenn man freilich am Board gespart
> hat...

Speicher und mehr als 32 Bit machen nur Sinn, wenn man vorher schon
alle Möglichkeiten ausgeschöpft hat ... von einer Trennung in zwei
oder mehr Systeme - WWW- und DB-Server getrennt - verspreche ich mir
auch mehr als vor einer Monster-Maschine. Billige Hardware hat den
Vorteil, dass sie leicht ausgetauscht ist ... siehe Prinzip "Google".
Zwei Maschinen, das heisst auch, dass die I/O getrennt ist und ein WWW-
Server hat u.U. ganz schön viel I/O ...

Gruß, Dirk

Re: MySQL, ein bischchen php & ärger ...

Clemens Zauner schrieb:

> Ist die Software wirklich so selbst herrlich, das nicht als tunable
> zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
> zur Suche, vermute aber immer mehr eine eine solche ganz woanders.

Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein
include-File, welches den Servernamen als Konstante oder Variable
definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
Thema "unfähigkeit"), der sich nun fürchterlich rächt. Diesen solltest
Du _jetzt_ ein- für allemal ausmerzen, anstatt zu versuchen, dieses
verkorkste Design von außen durch einen nicht minder verkorksten
Würgaround "lösen" zu wollen.

Gruß. Claus

Re: MySQL, ein bischchen php & ärger ...

Claus Reibenstein schrieb:
>
> Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
> hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein
> include-File, welches den Servernamen als Konstante oder Variable
> definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
> Thema "unfähigkeit"), der sich nun fürchterlich rächt. Diesen solltest
> Du _jetzt_ ein- für allemal ausmerzen, anstatt zu versuchen, dieses
> verkorkste Design von außen durch einen nicht minder verkorksten
> Würgaround "lösen" zu wollen.

Wenn das Skripte von Dritten sind, hat er gar nicht die Möglichkeit,
viel daran rumzuändern.
Und am expliziten Konfigurieren von user/host/port/passwort kommt man
beim Schreiben von PHP-Skripten in der Regel auch nicht herum.
Schließlich soll ja jeder, der auf einem Host untergebracht ist, seine
eigene Datenbank verwenden und nicht alle die gleiche.

Ich fürchte, da bleibt nichts anderes, als den Administratoren der
einzelnen Skripte den Umzug auf den neuen Datenbankhost schmackhaft zu
machen.
Oder, alternativ, eine Proxylösung zu finden und zu installieren. (Dazu
weiß ich aber nichts. Nach den bisherigen Reaktionen zu schließen, weiß
es auch sonst keiner hier.)

Grüße
Jo

Re: MySQL, ein bischchen php & ärger ...

On 8 Mai, 09:56, Joachim Durchholz wrote:
> Wenn das Skripte von Dritten sind, hat er gar nicht die Möglichkeit,
> viel daran rumzuändern.

Überleg' mal, was Du da schreibst! Wenn das Auftragsarbeit ist und man
nimmt das *so* ab ... also da hat doch jemand ganz gewaltig bei seinen
Hausaufgaben geschlampt! Und welches gut strukturierte Projekt kennst
Du, bei dem man nicht an einer Stelle, sondern an 100 hart kodierte
Konfigurationssequenzen vorfindet?

> Und am expliziten Konfigurieren von user/host/port/passwort kommt man
> beim Schreiben von PHP-Skripten in der Regel auch nicht herum.
> Schließlich soll ja jeder, der auf einem Host untergebracht ist, seine
> eigene Datenbank verwenden und nicht alle die gleiche.

Ja, aber das ist nicht an 100 Stellen, sondern jeweils zentral in
einer Include-Datei! Oder hälst Du es für verantwortbar, dass bei x
Installationen weltweit jedesmal derselbe User mit demselben Passwort
Anwendung findet?

> Oder, alternativ, eine Proxylösung zu finden und zu installieren.

Grausam ... und bei einem Unix-Socket wohl kaum machbar, es sei denn,
man schreibt sich selber einen Proxy von Unix Socket nach TCP/IP-
Socket ...

Gruß, Dirk

Re: MySQL, ein bischchen php & ärger ...

Clemens Zauner schrieb:
> Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).

Doch, das geht. suexec+fastcgi+php-fcgi löst das.
Erfordert allerdings ein paar Dateien im Rootverzeichnis jeder
DocumentRoot; Apache handhabt die CGI-Konfiguration in dieser Hinsicht
reichlich dämlich.

> Sorry, aber ich halte das Verhalten echt für grenzdebil. Das scheint
> nicht tunable zu sein - und anscheinend gibts nicht mal einen Fallback
> (wenn kein socket da, dann probiere doch mal TCP ...).

Jetzt mal davon abgesehen, dass es jedem Standard spottet, wenn man
zwischen localhost und 127.0.0.1 unterscheidet. Das ist wirklich Quark -
aber mysql macht's halt so.

Grüße
Jo

Re: MySQL, ein bischchen php & ärger ...

Am 08.05.2007 09:57 schrieb Dirk Ohme:
> On 8 Mai, 09:56, Joachim Durchholz wrote:
>> Wenn das Skripte von Dritten sind, hat er gar nicht die Möglichkeit,
>> viel daran rumzuändern.
>
> Überleg' mal, was Du da schreibst! Wenn das Auftragsarbeit ist und man
> nimmt das *so* ab ... also da hat doch jemand ganz gewaltig bei seinen
> Hausaufgaben geschlampt! Und welches gut strukturierte Projekt kennst
> Du, bei dem man nicht an einer Stelle, sondern an 100 hart kodierte
> Konfigurationssequenzen vorfindet?
>

Wenn ich Clemens richtig verstehe, dann geht es um einen Hoster. D.h.,
die vermieten ihre Rechner samt Software an Leute, die "mal schnell"
irgendwas in PHP/MySQL zusammenhacken. Also vermutlich die Klientel,
die in dieser Gruppe immer wieder aufschlägt mit Fragen nach
Rezeptdatenbanken, Bereinigung von Lücken in auto_increment-Spalten
u.ä. Weder Ahnung vom Programmieren noch Lust oder Zeit, sich damit zu
beschäftigen, und warum sollte man ein Handbuch lesen... Die machen
nun vermutlich das, was sie irgendwo mal aufgeschnappt haben, nämlich
mysql_connect() mit den "passenden" Parametern aufzurufen.

Ein Hoster könnte sich die Arbeit machen, seine User zu erziehen. Aber
warum sollte er? Das kostet Geld, treibt also den Preis für sein
Angebot nach oben und Kunden von ihm weg.

>> Und am expliziten Konfigurieren von user/host/port/passwort kommt man
>> beim Schreiben von PHP-Skripten in der Regel auch nicht herum.
>> Schließlich soll ja jeder, der auf einem Host untergebracht ist, seine
>> eigene Datenbank verwenden und nicht alle die gleiche.
>
> Ja, aber das ist nicht an 100 Stellen, sondern jeweils zentral in
> einer Include-Datei! Oder hälst Du es für verantwortbar, dass bei x
> Installationen weltweit jedesmal derselbe User mit demselben Passwort
> Anwendung findet?
>

Nun, es dürften verschiedene sein.

>> Oder, alternativ, eine Proxylösung zu finden und zu installieren.
>
> Grausam ... und bei einem Unix-Socket wohl kaum machbar, es sei denn,
> man schreibt sich selber einen Proxy von Unix Socket nach TCP/IP-
> Socket ...

Da MySQL Open Source ist, gibt es noch eine andere Lösung. So oft
aktualisieren Hoster ihre Installationen ja ohnehin nicht, da kann man
auch mal in den Quellen von MySQL 5.0.x rumbasteln. Das hält dann
vielleicht bis 6.1 ;-)

Re: MySQL, ein bischchen php & ärger ...

Dirk Ohme schrieb:
>
> Speicher und mehr als 32 Bit machen nur Sinn, wenn man vorher schon
> alle Möglichkeiten ausgeschöpft hat ... von einer Trennung in zwei
> oder mehr Systeme - WWW- und DB-Server getrennt - verspreche ich mir
> auch mehr als vor einer Monster-Maschine. Billige Hardware hat den
> Vorteil, dass sie leicht ausgetauscht ist ... siehe Prinzip "Google".
> Zwei Maschinen, das heisst auch, dass die I/O getrennt ist und ein WWW-
> Server hat u.U. ganz schön viel I/O ...

Fragt sich: was für IO?

Meist ist der Flaschenhals die Platte, nicht die RAM-Anbindung. Eine
zweite Platte dürfte da genau so viel bringen wie ein zweiter Server,
aber deutlich weniger Zeit, Geld und Nerven kosten.

Die Austauschbarkeit spricht natürlich eher für eine Zweitmaschine.
Andererseits ist der Administrationsaufwand deutlich höher. Ich spreche
da aus persönlicher Erfahrung: zwei Logs auf Unregelmäßigkeiten
abzuklappern, zwei Maschinen mit Updates zu versorgen, zweimal
regelmäßig Lizenzschlüssel nachzutragen, usw. usw. - und bei zwei
Maschinen lohnt sich eine Automatisierung noch nicht wirklich. (Ab zehn
Maschinen sieht das wieder anders aus.)

Grüße
Jo

Re: MySQL, ein bischchen php & ärger ...

Am 08.05.2007 10:01 schrieb Joachim Durchholz:

> Jetzt mal davon abgesehen, dass es jedem Standard spottet,

http://www.amazon.de/Dativ-ist-dem-Genitiv-sein/dp/346203448 0/ref=pd_bbs_sr_1/302-3765158-1095225?ie=UTF8&s=books&qid=11 78611807&sr=8-1

Re: MySQL, ein bischchen php & ärger ...

Joachim Durchholz wrote:
> Dirk Ohme schrieb:
>>
>> Speicher und mehr als 32 Bit machen nur Sinn, wenn man vorher schon
>> alle Möglichkeiten ausgeschöpft hat ... von einer Trennung in zwei
>> oder mehr Systeme - WWW- und DB-Server getrennt - verspreche ich mir
>> auch mehr als vor einer Monster-Maschine. Billige Hardware hat den
>> Vorteil, dass sie leicht ausgetauscht ist ... siehe Prinzip "Google".
>> Zwei Maschinen, das heisst auch, dass die I/O getrennt ist und ein WWW-
>> Server hat u.U. ganz schön viel I/O ...
>
> Fragt sich: was für IO?
>
> Meist ist der Flaschenhals die Platte, nicht die RAM-Anbindung. Eine
> zweite Platte dürfte da genau so viel bringen wie ein zweiter Server,
> aber deutlich weniger Zeit, Geld und Nerven kosten.

Genau dieses Herumraten, was denn nun der Flaschenhals ist und ob
es eine Limitation der Hardware-Plattform oder einzelner Hardware-
Komponenten ist - genau das könnte man sich ersparen, wenn man das
Problem erst mal analysieren würde, bevor man in hektische Betrieb-
samkeit verfällt.

Wenn man ein Haus bauen will, macht man ja auch erst das Fundament,
bevor man die Fassade pinselt.


XL

Re: MySQL, ein bischchen php & ärger...

Claus Reibenstein <4spammersonly@web.de> wrote:
> Clemens Zauner schrieb:
>
>> Ist die Software wirklich so selbst herrlich, das nicht als tunable
>> zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
>> zur Suche, vermute aber immer mehr eine eine solche ganz woanders.
>
> Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
> hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein
> include-File, welches den Servernamen als Konstante oder Variable
> definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
> Thema "unfähigkeit"), der sich nun fürchterlich rächt.

Wenn ich ihn richtig verstanden habe, sind das gar nicht seine Scripte
sondern die von irgendwelchen Usern/Kunden/whatever. Es ist also nicht
sein Designfehler.


> Diesen solltest Du _jetzt_ ein- für allemal ausmerzen, anstatt zu
> versuchen, dieses verkorkste Design von außen durch einen nicht minder
> verkorksten Würgaround "lösen" zu wollen.

Selbst wenn er den Kunden die richtige Einstellung (IP-Adresse statt
'localhost') vorgegeben hätte, hat er nun sein Problem: alle müssten
ihre Scripte ändern, weil sich die IP ändert. Da ist also nichts
dran zu ändern.

Nicht gleich immer losmotzen ...


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: MySQL, ein bischchen php & ärger ...

Andreas Scherbaum schrieb:

> Claus Reibenstein <4spammersonly@web.de> wrote:
>
>> Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
>> hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein
>> include-File, welches den Servernamen als Konstante oder Variable
>> definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
>> Thema "unfähigkeit"), der sich nun fürchterlich rächt.
>
> Wenn ich ihn richtig verstanden habe, sind das gar nicht seine Scripte
> sondern die von irgendwelchen Usern/Kunden/whatever. Es ist also nicht
> sein Designfehler.

Das hat auch niemand behauptet.

>> Diesen solltest Du _jetzt_ ein- für allemal ausmerzen, anstatt zu
>> versuchen, dieses verkorkste Design von außen durch einen nicht minder
>> verkorksten Würgaround "lösen" zu wollen.
>
> Selbst wenn er den Kunden die richtige Einstellung (IP-Adresse statt
> 'localhost')

Es geht nicht um Hostname statt IP-Adresse (was übrigens noch falscher
wäre). Bitte lies noch einmal, was ich geschrieben habe.

> Nicht gleich immer losmotzen ...

Wieso "losmotzen"? Motzen sieht anders aus.

Gruß. Claus

Re: MySQL, ein bischchen php & ärger ...

Axel Schwenke schrieb:

> Joachim Durchholz wrote:
>
> Wenn man ein Haus bauen will, macht man ja auch erst das Fundament,
> bevor man die Fassade pinselt.

Vor allem macht man erst mal einen Plan. Und wenn man dann erst beim
Bauen merkt, dass man die Toiletten vergessen hat, klatscht man halt
schnell noch irgendwelche hässlichen Dinger von außen dran (welches
Krankenhaus war das doch gleich?).

Gruß. Claus

Re: MySQL, ein bischchen php & ärger ...

Christian Kirsch schrieb:

> Am 08.05.2007 10:01 schrieb Joachim Durchholz:
>
>> Jetzt mal davon abgesehen, dass es jedem Standard spottet,
>
> http://www.amazon.de/Dativ-ist-dem-Genitiv-sein/dp/346203448 0/ref=pd_bbs_sr_1/302-3765158-1095225?ie=UTF8&s=books&qid=11 78611807&sr=8-1

-v

Gruß. Claus

Re: MySQL, ein bischchen php & ärger...

Claus Reibenstein <4spammersonly@web.de> wrote:
>
> Wenn ich Dich richtig verstehe, dann ist "localhost" in 100+ Scripten
> hardcodiert enthalten. Es gibt also keine zentrale Stelle wie z.B. ein

Ja. Klar.

> include-File, welches den Servernamen als Konstante oder Variable
> definiert. Hier liegt also ein eklatanter Designfehler vor (so viel zum
> Thema "unfähigkeit"), der sich nun fürchterlich rächt. Diesen solltest

Ich sehe schon - du hast meine Postings entweder nicht gelesen,
oder nicht verstanden. Das sind webpages von *irgendwelchen*
Leuten, Ich denke nicht, dass der anbietende Dienstleiter
derartige Vorschriften machen sollte.

BTW habe ich zumindest schon mal 2 Präsenzen gefunden, die überhaupt
einen ganz anderen DB-Server ganz woanders verwenden.

> Du _jetzt_ ein- für allemal ausmerzen, anstatt zu versuchen, dieses
> verkorkste Design von außen durch einen nicht minder verkorksten
> Würgaround "lösen" zu wollen.

Noch mal: Das ist keine Daddelbox ("root-server") für eine Gruppe/
Person. Dort tummelt sich alles mögliche. Der kleinste gemeinsame
Nenner ist der Account.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger...

Dirk Ohme wrote:
> On 8 Mai, 09:56, Joachim Durchholz wrote:
>> Wenn das Skripte von Dritten sind, hat er gar nicht die Möglichkeit,
>> viel daran rumzuändern.
>
> Überleg' mal, was Du da schreibst! Wenn das Auftragsarbeit ist und man
> nimmt das *so* ab ... also da hat doch jemand ganz gewaltig bei seinen
> Hausaufgaben geschlampt! Und welches gut strukturierte Projekt kennst
> Du, bei dem man nicht an einer Stelle, sondern an 100 hart kodierte
> Konfigurationssequenzen vorfindet?

Was sollte da wer wo was abnehmen? Das sind hunderte, von einander
absolut unabhängige Projekte. Service alà "Webspace + Database";
Wer von den Accountinhabern was wie wo genau macht - und ob die
überhaupt php und/oder MySQL nutzen bleibt jeweils denen überlassen.

> Ja, aber das ist nicht an 100 Stellen, sondern jeweils zentral in
> einer Include-Datei! Oder hälst Du es für verantwortbar, dass bei x
> Installationen weltweit jedesmal derselbe User mit demselben Passwort
> Anwendung findet?

Ebensoviele User, ebensolviele Passwörter.

>> Oder, alternativ, eine Proxylösung zu finden und zu installieren.
>
> Grausam ... und bei einem Unix-Socket wohl kaum machbar, es sei denn,
> man schreibt sich selber einen Proxy von Unix Socket nach TCP/IP-
> Socket ...

Ich dachte da eher an "Unix Socket<->IP<->Unix Socket". Quasi sowas
wie wie ssh-portforward, nur halt für Unix-Sockets.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger...

Clemens Zauner wrote:
> Axel Schwenke wrote:

[anscheinend zu subtile Hinweise]

>> -> man *kann* das hacken - wenn man es kann ;-)
>
> Das ist alles ganz schon und gut; aber umschreiben ist nicht. das Teil
> sollte wartbar bleiben. Immerhin haben ich die letzten 3 Monate damit
> verbracht solche "loesungen" wieder zu entfernen.

Lies mal hier (und lies *alles*)
http://dev.mysql.com/doc/refman/5.0/en/mysql-options.html

Man *kann* Nutzung des TCP-Protokolls erzwingen. Man *kann* das auch in
eine my.cnf schreiben. Allerdings muß man dem Client explizit sagen,
daß man die Einstellungen aus dieser my.cnf verwenden will. Anscheinend
bietet das die 'mysql' Erweiterung von PHP nicht - aber man könnte es
hineinhacken. Man könnte auch an wenigen strategisch günstigen Stellen
ein mysql_options(..., MYSQL_OPT_PROTOCOL, ...) in den Code einstreuen.


> Ist die Software wirklich so selbst herrlich, das nicht als tunable
> zumindest in my.cnf zu haben? Ich glaubte zuerst an meine unfähigkeit
> zur Suche, vermute aber immer mehr eine eine solche ganz woanders.

Deine Anpielungen kannst du dir sonstwohin stecken. MySQL kennt nun mal
das Konzept "lokale Verbindung" und reserviert dafür ein paar magische
Hostnamen. Ob "localhost" eine gute Wahl war, darüber kann man sicher-
lich streiten. Aber nachdem diese Wahl nun mal getroffen wurde, wird
sie mit Sicherheit nicht geändert - Kompatibilität ist zu wichtig.

Der eigentliche Fehler besteht darin, daß PHP-Skripte annehmen, ihr
MySQL-Server müßte immer auf "localhost" laufen. Wenn der Herr PHP-
Pr0gger nur semi-bekloppt war, hat er vielleicht gar keinen Hostnamen
angegeben. In diesem Fall könnte dir mysql.default_host in php.ini aus
der Patsche helfen.


Und bitte versteh mich nicht falsch: du hast mein Mitgefühl dafür, daß
du so einen Haufen Mist supporten mußt. Aber für die Typen die so einen
Scheiß verbrechen, habe ich gar kein Mitgefühl. Also geh und LARTe sie!


XL

Re: MySQL, ein bischchen php & ärger...

Alexander Wühr wrote:
> Eine (zugegebenermassen nicht schöne) Lösung wäre einfach ein ssh Tunnel.
>

Eben leider *nicht*.

> Anschließend startest Du auf dem Webserver
>
> ssh -Nfg -L3306:127.0.0.1:3306 dbtunnel@datenbankserver

Den Portforward habe ich bereits gemacht (ohne ssh-tunnel, es gibt
effizientere Methoden). Ein "mysql [...] -h 127.0.0.1" geht auf den
Webservern. Ich komme aus der Netzwerkecke - und vermeide im
Normalfall nach Massgabe alles über L4. Daher auch mein etwas
- im Nachhinein betrachtet - naiver Ansatz.

Das *Problem* ist das, dass mysql/php bei einem Open auf "localhost"
anstelle "127.0.0.1" nicht TCP-Ports verwendet, sondern ein Unix
Socket (z.B: /tmp/mysql/mysql.sock). Und genau genau *hier* birnts
dann die scripts natürlich mit einem Error auf.

> Der Charme dieser Lösung ist, daß das Forwarding für MySQL vollkommen
> transparent ist, und du keinerlei Anpassungen an den Benutzerrechten des
> MySQL Servers vornehmen musst. Es muß dort noch nicht einmal der Port
> 3306 offen sein, Port 22 reicht.

Portforward reicht leider nicht.

cu
Clemens.

Re: MySQL, ein bischchen php & ärger...

Joachim Durchholz wrote:
> Clemens Zauner schrieb:
>> Als allererstes liegt es mir mal
>> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
>> nicht mehr das, was ich unter "wartbar" verstehe).
^^^^^^^
> Doch, das geht. suexec+fastcgi+php-fcgi löst das.

Das "es geht" weiss ich auch. Ich habe das relevante oben mal
unterstrichen. Und unter "wartbar" verstehe ich nicht, dass ich
das "verstehe" und "handhaben kann" - sondern dass man das
Annähernd *jedem* in bestenfalls einer halben Stunde erklären
kann.

Ich will einfach eine minimale Anzahl von Sonderfällen in
den Konfigurationen.

> Jetzt mal davon abgesehen, dass es jedem Standard spottet, wenn man
> zwischen localhost und 127.0.0.1 unterscheidet. Das ist wirklich Quark -
> aber mysql macht's halt so.

Tja, wenn ich hier nicht in einer mysql-gruppe wäre, würde ich jetzt
ranten.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger...

Christian Kirsch wrote:
> Da MySQL Open Source ist, gibt es noch eine andere Lösung. So oft
> aktualisieren Hoster ihre Installationen ja ohnehin nicht, da kann man
> auch mal in den Quellen von MySQL 5.0.x rumbasteln. Das hält dann
> vielleicht bis 6.1 ;-)

Ich will mich da auf keinen Fall unersetzbar machen. Ich würde das
gerne funktionsfähig abgeben & dann nie wieder anschauen müssen, weil
es einfach funktioniert.

Source-Code gefrickel ist das IMO ein schlechter Ansatz.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger ...

Ok, UDP geht nicht, hab ich wohl in den vorherigen Postings überlesen.

Muß der Zugriff unbedingt über UDP erfolgen, oder könnte man nicht
einfach in der my.cnf den Eintrag "skip-networking" auskommentieren?


vlg

Alexander

Clemens Zauner schrieb:
> Alexander Wühr wrote:
>> Eine (zugegebenermassen nicht schöne) Lösung wäre einfach ein ssh Tunnel.
>>
>
> Eben leider *nicht*.
>
>> Anschließend startest Du auf dem Webserver
>>
>> ssh -Nfg -L3306:127.0.0.1:3306 dbtunnel@datenbankserver
>
> Den Portforward habe ich bereits gemacht (ohne ssh-tunnel, es gibt
> effizientere Methoden). Ein "mysql [...] -h 127.0.0.1" geht auf den
> Webservern. Ich komme aus der Netzwerkecke - und vermeide im
> Normalfall nach Massgabe alles über L4. Daher auch mein etwas
> - im Nachhinein betrachtet - naiver Ansatz.
>
> Das *Problem* ist das, dass mysql/php bei einem Open auf "localhost"
> anstelle "127.0.0.1" nicht TCP-Ports verwendet, sondern ein Unix
> Socket (z.B: /tmp/mysql/mysql.sock). Und genau genau *hier* birnts
> dann die scripts natürlich mit einem Error auf.
>
>> Der Charme dieser Lösung ist, daß das Forwarding für MySQL vollkommen
>> transparent ist, und du keinerlei Anpassungen an den Benutzerrechten des
>> MySQL Servers vornehmen musst. Es muß dort noch nicht einmal der Port
>> 3306 offen sein, Port 22 reicht.
>
> Portforward reicht leider nicht.
>
> cu
> Clemens.

Re: MySQL, ein bischchen php & ärger...

Daniel Fischer wrote:
>> Ist auf der Hardware keine Option mehr. Die Billige PC 32-Bit
>> Architektur hat gewisse Grenzen.
>
> 64 GiB ab Pentium. Sollte reichen. Wenn man freilich am Board gespart
> hat...

Nix da. 32-Bit System können in echt 4 GByte adressieren; dann zieht man
noch mal deutlich was für die PCI-Infrastruktur ab. Dei Systeme mit
>4Gbyte funktionieren nach der Rosstäuscher-methode.

Klar, die entsprechenden HW-Vendors behaupten natürlich ganz gerne
wie toll das doch alles sei. Unterm strich ist es halt das alte 64K-Page
switching in einer aufgebohrten Variante.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger...

Joachim Durchholz wrote:
>> Zwei Maschinen, das heisst auch, dass die I/O getrennt ist und ein WWW-
>> Server hat u.U. ganz schön viel I/O ...
>
> Fragt sich: was für IO?

Alles an IO.

> Meist ist der Flaschenhals die Platte, nicht die RAM-Anbindung. Eine
> zweite Platte dürfte da genau so viel bringen wie ein zweiter Server,
> aber deutlich weniger Zeit, Geld und Nerven kosten.

Wer spricht hier von einer Platte? Zur zeit ist das ein Array,
Das zielsystem/Die Zielsysteme läuft/laufen dann von einem Storage
runter (Sowas macht auch Freude beim backup).

> Die Austauschbarkeit spricht natürlich eher für eine Zweitmaschine.
> Andererseits ist der Administrationsaufwand deutlich höher. Ich spreche
> da aus persönlicher Erfahrung: zwei Logs auf Unregelmäßigkeiten
> abzuklappern, zwei Maschinen mit Updates zu versorgen, zweimal
> regelmäßig Lizenzschlüssel nachzutragen, usw. usw. - und bei zwei
> Maschinen lohnt sich eine Automatisierung noch nicht wirklich. (Ab zehn
> Maschinen sieht das wieder anders aus.)

Das ist kein Problem, und ensprechende Mechanismen sind bereits vorhanden.
Das ganze steht und fällt mit dem mysql-socket.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger ...

Hallo Clemens,

> Source-Code gefrickel ist das IMO ein schlechter Ansatz.

Eigentlich lebt ein solches Projekt davon, dass Zusatzfunktionen für die
ein Bedarf besteht nicht auf einem einzelnen Rechner verhungern sondern in
den Source einfliessen.


Siegfried
--
http://www.schmidt.ath.cx

Re: MySQL, ein bischchen php & ärger...

Axel Schwenke wrote:
> Genau dieses Herumraten, was denn nun der Flaschenhals ist und ob
> es eine Limitation der Hardware-Plattform oder einzelner Hardware-
> Komponenten ist - genau das könnte man sich ersparen, wenn man das
> Problem erst mal analysieren würde, bevor man in hektische Betrieb-
> samkeit verfällt.

Wie ich schon ein andermal schrieb: Ich betrachte das jetzt schon
seit Monaten. Als "hektische Betriebsamkeit" verstehe ich das nicht.

> Wenn man ein Haus bauen will, macht man ja auch erst das Fundament,
> bevor man die Fassade pinselt.

Tja - eben alles Analysiert und ein Konzept erarbeitet, das auch ein
paar Jährchen halten sollte. Quasi beim Alpha-Testing ist halt das
MySQL-verhalten aufgefallen (Unix Domain vs. IP-Socket).
Gut - ich eventuell etwas blauäugig. Aber auf diese "Feature" bin
ich nicht wirklich bei der Reissbrett-planung gekommen. Wenn das
die totale Frickelware wäre hätte ich mir das vorher sicher genauer
angeschaut. Aber seit ein paar Jahren tönt ja MySQL immer wie
unglaublich professionell das jetzt in der Zwischenzeit sei.

Bei solchen Stunts kann man eigentlich nur mehr den Kopf schütteln.
Und ich kann fast nicht glauben, dass mein Begehr so ungewöhnlich
ist. Es kann ja auch sein, dass man das Verhalten aus Kompatibilitäts-
gründen noch drinnen hat. Aber bis zur version 5-irgendwas waere
ein tunable hier wahrscheinlich a) wenig Arbeit gewesen und hätte
b) sogar einen echten Impact.

Eine andere Option wäre ein lightweigth-Server auf den Webhosts,
die einfach auf den Parent durchreichen - aber das findet sich
zumindest zur Zeit anscheinend auch nicht.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger...

Clemens Zauner!

> Daniel Fischer wrote:
>> 64 GiB ab Pentium. Sollte reichen. Wenn man freilich am Board gespart
>> hat...

^^ Das sollte "ab Pentium Pro" heißen.

> Nix da. 32-Bit System können in echt 4 GByte adressieren; dann zieht man
> noch mal deutlich was für die PCI-Infrastruktur ab. Dei Systeme mit
> >4Gbyte funktionieren nach der Rosstäuscher-methode.

"32-Bit-System" sagt erstmal nichts darüber aus, wieviel Speicher die CPU
adressieren kann, sondern nur, dass sie in einem Takt 32 Bit von irgendwas
verarbeiten kann.

Der 16-Bit-Prozessor 8086 konnte 1 MiB adressieren, der 16-Bit-Prozessor
80286 konnte 16 MiB adressieren, und Intel-x86-CPUs ab Pentium Pro haben
eben einen 36 Bit breiten Adressbus und können daher 64GiB RAM ansprechen
und nicht nur 4GiB.

> Klar, die entsprechenden HW-Vendors behaupten natürlich ganz gerne
> wie toll das doch alles sei. Unterm strich ist es halt das alte 64K-Page
> switching in einer aufgebohrten Variante.

Du suchst "Segmentierung". Page Switching habe ich aus 64k-Zeiten anders
in Erinnerung :-)


Gruß
Daniel

Re: MySQL, ein bischchen php & ärger...

Clemens Zauner wrote:
> Axel Schwenke wrote:
>>
>> Ich erlaube mir, daran zu zweifeln, daß die Analyse des Performance-
>> problems mit der gebotenen Sorgfalt erfolgt ist.
>
> Das sei dir unbenommen.

Schön. Dann sehen wir mal weiter ...

> Im Prinzip sehr einfach - die Webserver landen vorne, gemeisame storage
> Engine, ein gemeinsamer Datenbankhost. *Wo* die genau sind hat sie
> gar nichts anzugehen. Das skaliert.

Das skaliert nur in dem (unwahrscheinlichen) Fall, daß die Datenbank
Däumchen dreht während Apache/PHP auf dem Zahnfleisch kriechen.

Das Hauptproblem besteht aber darin, daß sich jetzt mehrere
Applikationen beeinflussen. Wenn eine den Datenbankserver mit einem
Tablescan über eine 20GB Tabelle lahm legt, stehen 10 andere
Applikationen weil ihre Datenbank auf die Platte wartet.

> Als allererstes liegt es mir mal
> am Herzen php4 und ph5 auseinanderzudröseln (das ist auf einer Kiste
> nicht mehr das, was ich unter "wartbar" verstehe).

Schau mal guck. Du hast also noch mehr Probleme vom Typ "Chaos".

> Später dann einfach die Sets jeweils +1 nehmen. Das skaliert und
> ist total hypsch redundant. Und wenn die Leistung knapp wird,
> schnallt man halt noch mehr http-frontends dran.

Dieses Rezept ist nur tauglich, wenn es um *eine* Anwendung geht.
Und auch dann wird man früher oder später an die Grenze kommen,
wo die Datenbank das Bottleneck ist. Wenn man Pech hat, ist auch
Replikation keine Lösung und dann hat man ein richtiges Problem!

BTDT

> Da bisher die DB immer auf "localhost" war, haben die alle natuerlich
> auch "localhost" in ihren Webpräsenzen verwendet. Da ist es jetzt
> aber Essig mit dem Ansatz "ein Datenbankhost".

Deswegen ist es auch einfacher, Applikation und Datenbank auf *einer*
Maschine zu halten. Es ist noch lange nicht sauber, aber es ist
wenigstens handhabbar.

>> M.a.W. du hast jetzt Chaos und dein Rezept ist "noch mehr Chaos".
>
> Das ist dann kein Chaos mehr. Das ist super sauber. Ein Storage, ein
> entsprechend ausstaffierter DB-Server, http-Frontends drangepappt.
> Letztere haben so den Vorteil dass sie leicht austauschbar sind.
> Und quasi beliebig vervielfältigt werden können.

Nur in der Theorie. In der Praxis hast du mehrere Versionen von MySQL
und PHP. Und womöglich Applikationen, die bestimmte Kombinationen
voraussetzen. Also nix 1x Datenbankserver.

Und ein Proxy kann alle MySQL Anfragen von einem Webserver nur auf
einen Datenbankserver umleiten. Also müssen alle Applikationen schon
mal die gleiche MySQL-Version mögen. Im Endeffekt brauchst du also
für jede Kombination von PHP- und MySQL-Version mindestens einen
Webserver.

>> Wenn du schon mehrere Server ins Auge faßt, dann migriere gleich ganze
>> Applikationen (also PHP-Code + zugehörige MySQL-Datenbank). Vorzugs-
>> weise die Applikationen, für die das einfach geht. Dem Rest kannst du
>> schon mal ankündigen, daß sie entweder ihren Code aufräumen oder mit
>> schlechter Performance leben müssen.
>
> Dann rennt wieder auf jeder Mühle ein Datenbankserver. Halte ich für
> extrem unaufgeräumt und nervig in der Maintainance.

Nur wenn man sich ungeschickt anstellt. Als Vorteil bekommt man
wesentlich bessere Möglichkeiten zum Tuning und Monitoring. Wenn 10
Applikationen auf einer Datenbank herumtrampeln, konkurrieren sie
ja z.B. auch um Caches. Es reichen schon 2 Applikationen um sich
gegenseitig die Caches leer zu schießen.


XL

Re: MySQL, ein bischchen php & ärger...

Axel Schwenke wrote:
>> Das ist alles ganz schon und gut; aber umschreiben ist nicht. das Teil
>> sollte wartbar bleiben. Immerhin haben ich die letzten 3 Monate damit
>> verbracht solche "loesungen" wieder zu entfernen.
>
> Lies mal hier (und lies *alles*)
> http://dev.mysql.com/doc/refman/5.0/en/mysql-options.html

Du wirst lachen, das hatte ich sogar.

> Man *kann* Nutzung des TCP-Protokolls erzwingen. Man *kann* das auch in
> eine my.cnf schreiben. Allerdings muß man dem Client explizit sagen,

Ich bin mittlerweile darauf gekommen, dass ein "protocol = TCP" in der
my.cnf anscheinend tatsächlich eine Reihe von Clients dazu bringt,
TCP zu verwenden (als default). Genauer gesagt habe ich da einfach
jemanden gefragt, der was davon versteht (von Datenbanken).

> daß man die Einstellungen aus dieser my.cnf verwenden will. Anscheinend
> bietet das die 'mysql' Erweiterung von PHP nicht - aber man könnte es

Ja. php ignoriert das. Anscheinend die ganze my.cnf. So verweifelt war
ich nämlich schon, dass ich nach der Doku in der C-API gesucht habe
(respekt vor dem Dokumentationsansatz).

> Deine Anpielungen kannst du dir sonstwohin stecken. MySQL kennt nun mal
> das Konzept "lokale Verbindung" und reserviert dafür ein paar magische
> Hostnamen. Ob "localhost" eine gute Wahl war, darüber kann man sicher-
> lich streiten. Aber nachdem diese Wahl nun mal getroffen wurde, wird
> sie mit Sicherheit nicht geändert - Kompatibilität ist zu wichtig.

Der Spass an der Sache ist, dass zum Beispiel "LOCALHOST" (oder auch
"LoCaLhOsT" dann sehr wohl über TCP ausweicht.

> Und bitte versteh mich nicht falsch: du hast mein Mitgefühl dafür, daß
> du so einen Haufen Mist supporten mußt. Aber für die Typen die so einen
> Scheiß verbrechen, habe ich gar kein Mitgefühl. Also geh und LARTe sie!

Ich wage mal zu behaupten, dass ein grossteil davon einfach nicht mehr
greifbar ist (gut, /me könnte jetzt nach den l33t coder-pseudonymen
googeln, die sich manchmal oben im Code finden, gleich neben so tollen
Statements wie "Linux RoXX" und d.gl.mehr)...

grml
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger ...

Clemens Zauner schrieb im Newsbeitrag
> Was sollte da wer wo was abnehmen? Das sind hunderte,
> von einander absolut unabhängige Projekte.

Dann bastel' Dir halt einen MySQL-Client, der Unix-Sockets deaktiviert
hat ... dann geht alles über TCP/IP. Du brauchst den Client bzw. die
libmysql.a nur einmal erzeugen ... so oft ändert sich das Protokoll
auch nicht, so dass Du bei einer MySQL-Serverumstellung aktiv werden
müsstest ...

Gruß, Dirk

Re: MySQL, ein bischchen php & ärger ...

Axel Schwenke schrieb im Newsbeitrag
> Lies mal hier (und lies *alles*)
> http://dev.mysql.com/doc/refman/5.0/en/mysql-options.html
>
> Man *kann* Nutzung des TCP-Protokolls erzwingen.

Mehr noch:
http://www.php.net/manual/en/ini.core.php#ini.sql.safe-mode

Zitat:
"sql.safe_mode boolean
If turned on, database connect functions that specify default values
will use those values in place of supplied arguments. For default
values see connect function documentation for the relevant database."

> Man *kann* das auch in eine my.cnf schreiben.

.... oder sich mit den Möglichkeiten bei PHP auseinander setzen!

Gruß, Dirk

Re: MySQL, ein bischchen php & ärger...

Thus spoke Dirk Ohme:
> On 8 Mai, 09:56, Joachim Durchholz
> wrote:
>
>> Wenn das Skripte von Dritten sind, hat er gar nicht die
>> Möglichkeit, viel daran rumzuändern.
>
> Überleg' mal, was Du da schreibst! Wenn das Auftragsarbeit
> ist und man nimmt das *so* ab ... also da hat doch jemand
> ganz gewaltig bei seinen Hausaufgaben geschlampt!
> [...]

Kurzer Reality-Check: Eine Webbastelei wird dann abgenommen,
wenn die Seite auf Chefs Computer nett aussieht.
Ich behaupte mal, von strukturierter Programmentwicklung,
womöglich auch noch mit QM haben die wenigsten Webdesign-Buden
überhaupt schon jemals etwas gehört, geschweige denn, daß sie's
anwenden würden.
Traurig, aber wahr. :-(


Tschüs,

Sebastian

--
http://www.baumaschinen-modelle.net
http://www.schwerlast-rhein-main.de

Re: MySQL, ein bischchen php & ärger...

Daniel Fischer wrote:
> "32-Bit-System" sagt erstmal nichts darüber aus, wieviel Speicher die CPU
> adressieren kann, sondern nur, dass sie in einem Takt 32 Bit von irgendwas
> verarbeiten kann.

Hüstel. Du ich komme eigentlich aus der Ecke (ist zwar schon > 1 Jahrzehnt
aus, aber) ... OK, ist hier Offtopic - kurz & knapp:

n-Bit Prozessoren beschreiben üblicherweise die Bitbreite der Register
in ebendiesen. Die Anzahl der ausgeführtes Adressleitungen kann durchaus
davon abweichen. Ein klassiches Beispiel ist z.B. der 68K - zwar 32 Bit,
der ausgefürte addressbus war aber nur 24 Bit breit.

Mitnichten hat das was mit Anzahl Zyklen/Instruction zu tun; eine
Anweisung auf einer 32 Bit Maschine kann gut mehrere Takte brauchen
(auch register - register). Sie kann auch mehrere Instructions/Cycle
abarbeiten. Depends.

> Der 16-Bit-Prozessor 8086 konnte 1 MiB adressieren, der 16-Bit-Prozessor
> 80286 konnte 16 MiB adressieren, und Intel-x86-CPUs ab Pentium Pro haben
> eben einen 36 Bit breiten Adressbus und können daher 64GiB RAM ansprechen
> und nicht nur 4GiB.

Es ist *nicht* zulässig die Begriffe "Registerbreite" und "Busbreite"
synonym zu verwenden. Das hat miteinander nichts zu tun; ist natürlich
oft idealerweise gleich.
Ein gutes Beispiel sind auch die FP-Register auf 32 Bit Maschinen; die
waren/sind nämlich üblicherweise breiter.

Abschliessend glaube ich auch noch, dass du da eigentlich ganz furchtbar
daneben liegst (müsste jetzt aber nachschauen); die P-Pro (686) hat(te)
AFAIR eine überarbeitete MMU (insbesonders einen neuen TLB) der eben
einen grösseren Speicher verwenden konnte. Wegen der Dramatik der
dabei geschehenden Cache-Invalidations wurde der Datenbus auf 64 Bit
aufgebohrt, damit der wieder flotter mit RAM-Inhalt befüllt werden
konnte.
Irgendwie hat sich das ganze auch nicht wirklich durchgesetzt. Thank
$DEITY.

>> Klar, die entsprechenden HW-Vendors behaupten natürlich ganz gerne
>> wie toll das doch alles sei. Unterm strich ist es halt das alte 64K-Page
>> switching in einer aufgebohrten Variante.
> Du suchst "Segmentierung". Page Switching habe ich aus 64k-Zeiten anders
> in Erinnerung :-)

Ach ja. Das war der Begriff. Das war immer das abschreckende Beispiel
wie grauenvoll CPUs sein können. Zumindest für die Assembler-Jungs
anderer Architekturen. Es gab noch mehr.


--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS

Re: MySQL, ein bischchen php & ärger...

Clemens Zauner writes:

> ich nicht wirklich bei der Reissbrett-planung gekommen. Wenn das
> die totale Frickelware wäre hätte ich mir das vorher sicher genauer
> angeschaut. Aber seit ein paar Jahren tönt ja MySQL immer wie
> unglaublich professionell das jetzt in der Zwischenzeit sei.

wieso sollten die besser als die anderen sein? glauben gerade in der edv nicht
sehr viele sie wären die einzige koryphäe auf der welt und alle anderen sind
doof? sieht man doch fast täglich in den newsgroups :-)

> Bei solchen Stunts kann man eigentlich nur mehr den Kopf schütteln.
> Und ich kann fast nicht glauben, dass mein Begehr so ungewöhnlich

alle automatismen haben das problem dass der programmierer schlauer als der
anwender sein will. geht doch fast immer schief, natürlich liegts dann an der
magelnden anpassungfähigkeit des anwenders :-)

ps: geht das mit dem localhost jetzt endlich unter mac osx client?

Re: MySQL, ein bischchen php & ärger...

Clemens Zauner!

> n-Bit Prozessoren beschreiben üblicherweise die Bitbreite der Register

Dann haben wir da unterschiedliche Definitionen.

> in ebendiesen. Die Anzahl der ausgeführtes Adressleitungen kann durchaus
> davon abweichen. Ein klassiches Beispiel ist z.B. der 68K - zwar 32 Bit,
> der ausgefürte addressbus war aber nur 24 Bit breit.

Der 68000 kann mit 32-Bit-Adressen umgehen. Der Datenbus ist aber nur 16
Bit breit. Erst der 68020 ist ein echter 32-Bit-Prozessor mit
32-Bit-Datenbus und 32-Bit-ALU. Also, nach meiner Definition.

> Mitnichten hat das was mit Anzahl Zyklen/Instruction zu tun; eine
> Anweisung auf einer 32 Bit Maschine kann gut mehrere Takte brauchen
> (auch register - register). Sie kann auch mehrere Instructions/Cycle
> abarbeiten. Depends.

Úber Zyklen/Instruction habe ich nichts geschrieben, lies nochmal.

>> Der 16-Bit-Prozessor 8086 konnte 1 MiB adressieren, der 16-Bit-Prozessor
>> 80286 konnte 16 MiB adressieren, und Intel-x86-CPUs ab Pentium Pro haben
>> eben einen 36 Bit breiten Adressbus und können daher 64GiB RAM ansprechen
>> und nicht nur 4GiB.
>
> Es ist *nicht* zulässig die Begriffe "Registerbreite" und "Busbreite"
> synonym zu verwenden. Das hat miteinander nichts zu tun; ist natürlich
> oft idealerweise gleich.

Wo habe ich das? Ich habe doch genau das Gegenteil behauptet: Ab Pentium
Pro ist der Adressbus mindestens 36 Bit breit. Das hat nun überhaupt
nichts damit zu tun, dass die Register 16, 32 oder 64 Bit breit sind
(letzteres relativ früh, wenn man FPU oder MMX gelten lässt).

> Abschliessend glaube ich auch noch, dass du da eigentlich ganz furchtbar
> daneben liegst (müsste jetzt aber nachschauen); die P-Pro (686) hat(te)
> AFAIR eine überarbeitete MMU (insbesonders einen neuen TLB) der eben
> einen grösseren Speicher verwenden konnte.

Die MMU kann in einen Modus geschalten werden, in dem die page table bis
zu 64GiB verwalten kann. Eine normale 32-Bit-Anwendung merkt davon nichts,
und hat weiterhin nur 4GiB Adressraum. Das Stichwort ist PAE. Ich weiß
zumindest von Linux und Solaris, dass sie das unterstützen, Windows
ebenso.

http://msdn2.microsoft.com/en-us/library/aa366796.aspx

InnoDB kann übrigens AWE benutzen, um wieder halbwegs on-topic zu kommen :-)

> Ach ja. Das war der Begriff. Das war immer das abschreckende Beispiel
> wie grauenvoll CPUs sein können. Zumindest für die Assembler-Jungs
> anderer Architekturen. Es gab noch mehr.

Meine erste x86-CPU war glaube ich ein PII. Eben etwa zu dem Zeitpunkt,
als ich Atari aufgegeben habe :-)


Gruß
Daniel

Re: MySQL, ein bischchen php & ärger ...

Clemens Zauner schrieb:
> Daniel Fischer wrote:
>> Du suchst "Segmentierung".
>
> Ach ja. Das war der Begriff. Das war immer das abschreckende Beispiel
> wie grauenvoll CPUs sein können.

Segmente sind eigentlich nichts Schlimmes.
Dass das im 8086 so grauenvoll war, lag in erster Linie daran, dass die
Handhabung von Segmentadressen grotesk umständlich war, d.h. der
Befehlssatz war falsch aufgebaut. Zur Umständlichkeit kam dann noch
Unsicherheit dazu, weil Segmente sich überlappen konnten und das in der
Praxis auch häufig taten.

Segmente sind eine gute Idee, aber im 8086 haben sie fast alles falsch
gemacht, was man damit falsch machen kann...

Grüße
Jo

Re: MySQL, ein bischchen php & ärger ...

Daniel Fischer schrieb im Newsbeitrag
> Der 68000 kann mit 32-Bit-Adressen umgehen. Der Datenbus
> ist aber nur 16 Bit breit. Erst der 68020 ist ein echter
> 32-Bit-Prozessor mit 32-Bit-Datenbus und 32-Bit-ALU.
> Also, nach meiner Definition.

Nach *Deiner* Definition ist ein 80386-Prozessor ein
16/32-Bit-Prozessor, denn er lässt sich auf 16-Bit-Datenbusbreite per
Signalleitung umschalten (dauerhaft beim 80386SX realisiert, beim
80386DX per Leitung steuerbar).

Zum Glück gibt es noch andere Definitionen und die sind in Fachkreisen
anerkannt ... aber Du hast Recht: Jeder kocht sein eigenes Süppchen!
Sehr gebräuchlich ist aber die Definition über die internen
CPU-Register, wobei das bspw. beim Z80-Prozessor auch zu einem
7/8/16-Bit-Prozessor führt (das R-Register hat 7 signifikante Bits,
die meisten CPU-Register 8 Bits, lassen sich aber über bestimmte
Befehle zu 16-Bit-Register zusammenfassen, bspw. D+E -> DE ... wie
auch beim 8086/8088 mit den Multiplikations-/Divisionsbefehlen).

Gruß, Dirk

Re: MySQL, ein bischchen php & ärger...

Clemens Zauner wrote:

> Ich dachte da eher an "Unix Socket<->IP<->Unix Socket". Quasi sowas
> wie wie ssh-portforward, nur halt für Unix-Sockets.

Vielleicht hilft Dir socat weiter.

Allerdings wäre es empfehlenswert, diese Krücke nur bei den Webservern
für Bestandskunden zu aktivieren. Alle *neuen* Kunden kommen auf einen
(oder mehrere) Server, die diese Krücke nicht haben - die sollen dann
einen vorgegebenen DB-Servernamen verwenden.


Thomas
--
Windows 98 - from the people who brought you EDLIN

Re: MySQL, ein bischchen php & ärger ...

On 8 Mai, 10:08, Joachim Durchholz wrote:
> Fragt sich: was für IO?

In diesem Zusammenhang ist es für mich immer die Anbindung von
Peripherie - Festplatte(n), Netzwerk, usw., also die Ein-/Ausgaben vom/
zum System, welches aus CPU und Arbeitsspeicher besteht (CPU+RAM sehe
ich als Einheit - alles andere macht nur bedingt Sinn).

> Meist ist der Flaschenhals die Platte, nicht die RAM-Anbindung.
> Eine zweite Platte dürfte da genau so viel bringen wie ein zweiter
> Server, aber deutlich weniger Zeit, Geld und Nerven kosten.

Überleg's Dir mal gut, was Du sagst ... wenn's ein Produktivsystem
ist, dann wird schon aus einer gewissen Existenzsicherung wenigstens
RAID-1, eher RAID-5/6 gefahren. Ein System mit nur einer Platte ...
pardon, aber da hat jemand schon in der Planung etwas geschlafen ...

Man kann sich dann auch noch überlegen, ob "System" und "Daten" auf
getrennten Platten laufen, d.h. das System auf einer einzelnen Platte
und die Daten auf einem RAID-Verbund (die System-Partition zieht man
leicht wieder aus einem Image hoch, da lohnt ein RAID eigentlich
nicht).

> Die Austauschbarkeit spricht natürlich eher für eine Zweitmaschine.

Eine Zweitmaschine kann auch die Redundanz des jeweils anderen Systems
bedeuten: Der WWW-Server hat einen DB-Server in Reserve, der DB-Server
einen WWW-Server in Reserve. Sind die RAIDs nicht intern, sondern
extern angehängt, dann kann durch Umhängen der Notfallbetrieb sehr
schnell aufgenommen werden, falls nicht beide Systeme die beiden RAIDs
parallel anhängen haben (ein RAID für Dateien, ein RAID für die
Datenbank - SCSI lässt ja mehrere Host-Adapter auf einem Bus zu).

> Andererseits ist der Administrationsaufwand deutlich höher. Ich spreche
> da aus persönlicher Erfahrung: zwei Logs auf Unregelmäßigkeiten
> abzuklappern, zwei Maschinen mit Updates zu versorgen, zweimal
> regelmäßig Lizenzschlüssel nachzutragen, usw. usw. - und bei zwei
> Maschinen lohnt sich eine Automatisierung noch nicht wirklich. (Ab zehn
> Maschinen sieht das wieder anders aus.)

Ich weiss nicht, wie Du die Maschinen administriert hast, aber syslog
kann man zentralisieren - ansonsten automatisiert man die
Protokollauswertung. Es spricht auch nichts dagegen, die beiden
Maschinen identisch einzurichten, wobei der jeweilige Backup-Teil
schlafen gelegt ist. Und was für Lizenzschlüssel brauchst Du? Wir
reden hier von PHP und MySQL! Aber selbst in der Windows-Welt sind
Lizenzserver üblich ... eine zentrale Administration ebenso, sowie ein
zentrales Patch-Management (WSUS).

Also wenn jemand schon bei zwei Servern Probleme hat, dann sollte er
sich mal überlegen, wie er seine Probleme in den Griff bekommen
will ... denn mit spätestens einem Testsystem hat er einen dritten
Server im Bund - oder testest Du neuen Code auf der Produktivmaschine?
Um Himmels Willen ... !

Gruß, Dirk

Re: MySQL, ein bischchen php & ärger ...

Dirk Ohme schrieb:
>
> Überleg's Dir mal gut, was Du sagst ... wenn's ein Produktivsystem
> ist, dann wird schon aus einer gewissen Existenzsicherung wenigstens
> RAID-1, eher RAID-5/6 gefahren. Ein System mit nur einer Platte ...
> pardon, aber da hat jemand schon in der Planung etwas geschlafen ...

Das hängt schwer davon ab, was für ein Produktivsystem das ist.
Eine reine Werbe-Website, die schon mal einen halben Tag ausfallen darf,
ist mit einem nächtlichen Backup ausreichend abgesichert.
Bei einem Online-Shop sieht's schon anders aus, wenn da nennenswerte
Umsätze drüber laufen.
Bei einer Prozesssteuerung lohnen sich dann die ganz drastischen
Maßnahmen, da geht jede Stunde Stillstand in die zehntausende, evtl.
sogar mehr.

> Man kann sich dann auch noch überlegen, ob "System" und "Daten" auf
> getrennten Platten laufen, d.h. das System auf einer einzelnen Platte
> und die Daten auf einem RAID-Verbund (die System-Partition zieht man
> leicht wieder aus einem Image hoch, da lohnt ein RAID eigentlich
> nicht).

Das ist richtig, aber andererseits kompliziert es das System (höheres
Gesamt-Ausfallrisiko und ein klein wenig mehr Wartung).
Wenn das RAID-System den Platz ohnehin übrig hat, kann man das System
auch ohne weiteres mit draufpacken.
Die Verteilung auf eine zusätzliche Platte steigert natürlich die
Gesamtperformance, allerdings würde ich wohl selbst dann sagen, dass es
mehr bringt, wenn die zusätzliche Platte ebenfalls im RAID-Verbund
steckt, dann haben nicht nur Zugriffe auf die Systemdateien etwas davon.

>> Andererseits ist der Administrationsaufwand deutlich höher. Ich spreche
>> da aus persönlicher Erfahrung: zwei Logs auf Unregelmäßigkeiten
>> abzuklappern, zwei Maschinen mit Updates zu versorgen, zweimal
>> regelmäßig Lizenzschlüssel nachzutragen, usw. usw. - und bei zwei
>> Maschinen lohnt sich eine Automatisierung noch nicht wirklich. (Ab zehn
>> Maschinen sieht das wieder anders aus.)
>
> Ich weiss nicht, wie Du die Maschinen administriert hast,

Das meiste von Hand zu Fuß.
Ich eigne mir den Werkzeugsatz grad erst an.

> aber syslog kann man zentralisieren - ansonsten automatisiert man die
> Protokollauswertung. Es spricht auch nichts dagegen, die beiden
> Maschinen identisch einzurichten, wobei der jeweilige Backup-Teil
> schlafen gelegt ist.

Identische Einrichtung ist wohl das Minimum, sonst wird man nur noch
wahnsinnig.
Allerdings bringt die Automatisierung bei zwei Maschinen halt noch am
wenigsten Effekt, deshalb wird sie bei so kleinen Maschinenparks noch am
wenigsten gemacht.

> Und was für Lizenzschlüssel brauchst Du? Wir
> reden hier von PHP und MySQL!

Confixx, Plesk und ähnlichen Kram.
Das ist jetzt mehr für Shared Hosting, aber es gibt auch andere
lizenzpflichtige Software.
Wenn man so was nicht hat, ist das natürlich kein Thema. Dafür gibt's
dann in der Regel andere Besonderheiten, die für jede Maschine einzeln
gehandhabt werden müssen. Eine vollständige Automatisierung ist oft
nicht erreichbar (und sei's nur, weil der Admin die Zeit nicht kriegt,
die er bräuchte, um die Automatismen zu installieren und testen - das
ist dann zwar kurzsichtig, aber nicht jeder kann sich's aussuchen).

> Aber selbst in der Windows-Welt sind
> Lizenzserver üblich ... eine zentrale Administration ebenso, sowie ein
> zentrales Patch-Management (WSUS).

Wenn's das gibt.
Wenn man irgendeine Software laufen hat, wo's so einen Lizenzmanager
nicht für gibt, dann schaut man eben in die Röhre.

> Also wenn jemand schon bei zwei Servern Probleme hat, dann sollte er
> sich mal überlegen, wie er seine Probleme in den Griff bekommen
> will ...

Natürlich.
Das ist halt eine ziemlich steile Lernkurve. Man prokelt mit dutzenden
Tools herum, weiß nie so genau, ob die Probleme am Tool oder an einer
übersehenen Einstellung in der Konfiguration liegen, und ob das nächste
Tool wirklich besser ist. Googelt man nach Ratschlägen, findet man
selbst für die letzte Schrottsoftware noch begeisterte Kommentare zu
lesen. (Hab ich grad mit SysCP, das ist nicht wirklich prickelnd, aber
die Alternativen kosten entweder zuviel Geld für's Budget, oder es gibt
keine Sicherheitsupdates, oder sie können nicht, was ich bräuchte. Ein
einziges kann mehrere Maschinen verwalten, aber das ist irgendwo in
pre-Alpha. Irgendwann schreib ich mein eigenes Control Panel für Shared
Hosting... wenn der Leidensdruck endgültig zu groß wird und ich mal
reichlich freie Zeit habe. Vielleicht in zwanzig oder dreißig Jahren.)

> denn mit spätestens einem Testsystem hat er einen dritten
> Server im Bund - oder testest Du neuen Code auf der Produktivmaschine?

Nee, bloß nicht... dafür gibt's VMWare.
:-)

Das schützt einen nicht vor allen Fehlern, aber davor schützt auch eine
Testmaschine ja nicht wirklich.

Grüße
Jo

Re: MySQL, ein bischchen php & ärger ...

On 10 Mai, 11:29, Joachim Durchholz wrote:
> Das hängt schwer davon ab, was für ein Produktivsystem das ist.

... also dann sollte man sich an einen Provider wenden, wenn man die
lokale Administration scheut ...

[..]
> Wenn das RAID-System den Platz ohnehin übrig hat, kann man das System
> auch ohne weiteres mit draufpacken.

Um was geht es hier? Performance! Was macht man dann nicht? Bitte
bleib' bei der Argumentationskette und springe nicht auf einen anderen
Zug ... entweder, wir diskutieren über Performance und was wieviel
bringt, oder wir lassen es bleiben!

> Die Verteilung auf eine zusätzliche Platte steigert natürlich die
> Gesamtperformance, allerdings würde ich wohl selbst dann sagen, dass es
> mehr bringt, wenn die zusätzliche Platte ebenfalls im RAID-Verbund
> steckt, dann haben nicht nur Zugriffe auf die Systemdateien etwas davon.

Kennst Du Dich eigentlich mit RAID aus? Also wenn Du RAID-1 hast, dann
frage ich mich, was Du mit *einer* zusätzlichen Platte im RAID-Verbund
anstellen willst ...

> Das meiste von Hand zu Fuß.
> Ich eigne mir den Werkzeugsatz grad erst an.

Das merkt man ...

> Identische Einrichtung ist wohl das Minimum, sonst wird man nur noch
> wahnsinnig. Allerdings bringt die Automatisierung bei zwei Maschinen
> halt noch am wenigsten Effekt, deshalb wird sie bei so kleinen
> Maschinenparks noch am wenigsten gemacht.

Also bitte! Ein "dd" bei Unix oder eine Spiegelung bei einem
Windowssystem mit Neuvergabe das SID ... wo ist das Problem? Wenn es
nur um das schnelle Erstellen eines zweiten Systems geht, wer hindert
Dich dann, dort erstmal mit dem Backup des ersten Systems zu arbeiten,
wenn es nur darum geht, schnell einen identischen Zustand zu haben?

> > reden hier von PHP und MySQL!
> Confixx, Plesk und ähnlichen Kram.
> Das ist jetzt mehr für Shared Hosting, aber es gibt auch andere
> lizenzpflichtige Software.

Sorry, ich kam noch in einer Zeit mit der Thematik in Berührung, als
es solche Tools nicht gab und man sich über die Kommandozeile an die
Sache machte! (Ist mir auch heute noch lieber ...)

>[...] Eine vollständige Automatisierung ist oft nicht erreichbar
> (und sei's nur, weil der Admin die Zeit nicht kriegt, die er
> bräuchte, um die Automatismen zu installieren und testen - das
> ist dann zwar kurzsichtig, aber nicht jeder kann sich's aussuchen).

Nochmal: Der kürzesteste Weg dürfte über das Einspielen eines Backups
gehen ... und sowas kann auch über Nacht gehen. Ist übrigens ein
primat Test, ob das Backup überhaupt funktioniert ;-)

> Wenn's das gibt.
> Wenn man irgendeine Software laufen hat, wo's so einen Lizenzmanager
> nicht für gibt, dann schaut man eben in die Röhre.

Nun, eines sollte klar sein: Hat man zwei Maschinen parallel in
betrieb, dann braucht man auch zwei Lizenzen. Und es sollte klar sein,
dass der Hersteller der Software einen Weg zur Sicherung und
Wiederherstellung der Lizenzschlüssel anbieten sollte ...

> Natürlich.
> Das ist halt eine ziemlich steile Lernkurve. Man prokelt mit dutzenden
> Tools herum, weiß nie so genau, ob die Probleme am Tool oder an einer
> übersehenen Einstellung in der Konfiguration liegen, und ob das nächs=
te
> Tool wirklich besser ist. [...]

Pardon, was ist das für eine Vorgehensweise? Man sollte erstmal die
Grundlagen verstehen - das sind: Unix, Web-Server, DB-Server,
Programmiersprachen ... also beispielsweise Linux, Apache, MySQL, PHP,
Perl, Shell Script ... bevor man damit nicht klar kommt, sollte man
nicht erst versuchen, über eine höhere Ebene den Zugang zu finden!

Im Falle eines Falles ist der beste Zugang immer noch über eine
(secure) shell und wenn Du dann nicht mit den Konfigurationsdateien im
Editor (vi ;-) ) klar kommst, dann hast Du echt ein Problem. Auch
sollte man das virtuelle Hosting auf dem Apache mit PHP einrichten und
verstehen können, denn sonst hat man bei einem größeren Update dort
möglicherweise das Problem, dass die Administrationsoberfläche nicht
mehr tut ...

> Googelt man nach Ratschlägen, findet man selbst für
> die letzte Schrottsoftware noch begeisterte Kommentare
> zu lesen.

Nochmal: Deshalb erstmal die Grundlagen! Ist mühsam, ist hart, aber
wenn man die mal verstanden hat, dann weiss man, wieviel Geld man
dadurch spart, dass man solche Tools eben nicht braucht ... im übrigen
haben viele Unix-Derivate eine passable administrative Oberfläche
bereits mitgeliedert. Ich habe unter HP/UX auch oft auf "sam"
zurückgegriffen und nicht die Dateien zu Fuss editiert ...

> > Server im Bund - oder testest Du neuen Code auf der Produktivmaschine?
> Nee, bloß nicht... dafür gibt's VMWare.
> :-)

Nun ja ... mittlerweile gibt es VMWare, aber auch virtuelle Maschinen
habe ich zum Abstürzen gebracht, wo die Testmaschine ohne Anstand
funktionierte. Virtuelle Maschinen sind halt keine realen
Maschinen ... umgekehrt wirst Du gewisse Optimierungen an Kernel-
Parametern auch nicht in der virtuellen Maschine austesten können oder
andere Hardware ;-)

Und: Zum Testen tut's eine alte Kröte oder ein billiger PC ...

> Das schützt einen nicht vor allen Fehlern, aber davor schützt auch ei=
ne
> Testmaschine ja nicht wirklich.

Nein, gewisse last-abhängigen Sachen wird man dort nur unzureichend
nachstellen können - aber eine getrennte Hardware (Test-PC <->
Entwicklungs-PC mit Monitoring des Test-PC) erlaubt eine genauere
Analyse. Es nützt Dir nichts, wenn die virtuelle Maschine den Host-PC
derart in die Knie zieht, dass der Last-auslösende Prozess auf dem
Host-PC ebenfalls blockiert wird ...

Gruß, Dirk

Re: MySQL, ein bischchen php & ärger ...

Dirk Ohme schrieb:
>
>> Die Verteilung auf eine zusätzliche Platte steigert natürlich die
>> Gesamtperformance, allerdings würde ich wohl selbst dann sagen, dass es
>> mehr bringt, wenn die zusätzliche Platte ebenfalls im RAID-Verbund
>> steckt, dann haben nicht nur Zugriffe auf die Systemdateien etwas davon.
>
> Kennst Du Dich eigentlich mit RAID aus? Also wenn Du RAID-1 hast, dann
> frage ich mich, was Du mit *einer* zusätzlichen Platte im RAID-Verbund
> anstellen willst ...

Nee, klar doch.
Ich wollte jetzt nur nicht einen Grundlagenartikel zu LVM, RAID und
Striping vom Stapel lassen, das würde in einem mysql-Forum wirklich zu
weit führen.

>> Identische Einrichtung ist wohl das Minimum, sonst wird man nur noch
>> wahnsinnig. Allerdings bringt die Automatisierung bei zwei Maschinen
>> halt noch am wenigsten Effekt, deshalb wird sie bei so kleinen
>> Maschinenparks noch am wenigsten gemacht.
>
> Also bitte! Ein "dd" bei Unix oder eine Spiegelung bei einem
> Windowssystem mit Neuvergabe das SID ... wo ist das Problem? Wenn es
> nur um das schnelle Erstellen eines zweiten Systems geht, wer hindert
> Dich dann, dort erstmal mit dem Backup des ersten Systems zu arbeiten,
> wenn es nur darum geht, schnell einen identischen Zustand zu haben?

Na, jetzt muss ich aber zurückschießen: man merkt, dass Du die Wartung
von wenigen Servern nicht Dein Spezialgebiet ist.
Das Problem sind nicht identische Zustände, sondern ähnliche. Das
Grundsystem ist in einer halben Stunde überspielt und angepasst, aber
man muss ja regelmäßig Sicherheitsupdates einspielen, Logs kontrollieren
(ja, lässt sich zentralisieren, wenn man eine DoS-Schwachstelle
aufreißen will... oder man installiert einen syslog-ng, der dann aber
wieder andere Probleme mit sich bringt, für die er selbst nur wenig
kann, aber es kostet dann doch wieder Zeit).

Nee, keine Windows-Server. Da wüsste ich nicht mal, wo anfangen beim
Stopfen der Sicherheitslücken. Das ist schon bei Linux ein unangenehm
aufwändiges Thema.

>>> reden hier von PHP und MySQL!
>> Confixx, Plesk und ähnlichen Kram.
>> Das ist jetzt mehr für Shared Hosting, aber es gibt auch andere
>> lizenzpflichtige Software.
>
> Sorry, ich kam noch in einer Zeit mit der Thematik in Berührung, als
> es solche Tools nicht gab und man sich über die Kommandozeile an die
> Sache machte! (Ist mir auch heute noch lieber ...)

Mir auch, aber unsere Kunden können das nicht.
Die *sollen* das auch nicht. Da machen sie zu viel falsch und hängen
dann am Supporttelefon. (Gottseidank können sie nur noch eigenen Kram
kaputtmachen. Als ich die Rechneradministration übernommen habe, gab es
noch gegenseitige Störungsmöglichkeiten...)

>> Natürlich.
>> Das ist halt eine ziemlich steile Lernkurve. Man prokelt mit dutzenden
>> Tools herum, weiß nie so genau, ob die Probleme am Tool oder an einer
>> übersehenen Einstellung in der Konfiguration liegen, und ob das nächste
>> Tool wirklich besser ist. [...]
>
> Pardon, was ist das für eine Vorgehensweise? Man sollte erstmal die
> Grundlagen verstehen - das sind: Unix, Web-Server, DB-Server,
> Programmiersprachen ... also beispielsweise Linux, Apache, MySQL, PHP,
> Perl, Shell Script ... bevor man damit nicht klar kommt, sollte man
> nicht erst versuchen, über eine höhere Ebene den Zugang zu finden!

Der ist gut. Das sind alles schon längst abgehakte Themen, teilweise
seit Jahrzehnten.
Aber versuch mal ein problemloses Backup-Programm zu finden. Eines, das
eine Deltakompression kann, mit LVM-Snapshots zusammenspielt, und die
Backups den Anwendern einfach als Dateisystemhierarchie präsentiert. Die
Tools, die ich bisher durchprobiert habe, konnten immer nur höchstens
90% davon, aber wenn man nicht schon etliches davon im produktiven
Einsatz hat, weiß man nie, auf welche 10% man verzichten kann.

>>> Server im Bund - oder testest Du neuen Code auf der Produktivmaschine?
>> Nee, bloß nicht... dafür gibt's VMWare.
>> :-)
>
> Nun ja ... mittlerweile gibt es VMWare, aber auch virtuelle Maschinen
> habe ich zum Abstürzen gebracht, wo die Testmaschine ohne Anstand
> funktionierte.

Geht auch mit Testservern.
Wie ich schon sagte: ein Restrisiko bleibt immer.

> Virtuelle Maschinen sind halt keine realen
> Maschinen ... umgekehrt wirst Du gewisse Optimierungen an Kernel-
> Parametern auch nicht in der virtuellen Maschine austesten können oder
> andere Hardware ;-)

Da lass ich auch die Finger von.
Nicht, weil ich's nicht könnte, sondern weil die paar halben Prozent
Leistungsgewinn den Zeitaufwand und das Risiko einfach nicht wert sind.

Sollte der Maschinenpark mal auf 100 Maschinen anwachsen, bringt ein
Prozent Leistungsgewinn tatsächlich ein bisschen was, denn man spart
dann die Anschaffung der hundertersten Maschine.
Aber selbst in dem Fall wäre es sehr fraglich, ob es die Arbeitszeit
überhaupt wert ist...

> Und: Zum Testen tut's eine alte Kröte oder ein billiger PC ...

Die reagieren auf Kerneltuning aber auch nicht so wie der Produktivserver.

>> Das schützt einen nicht vor allen Fehlern, aber davor schützt auch eine
>> Testmaschine ja nicht wirklich.
>
> Nein, gewisse last-abhängigen Sachen wird man dort nur unzureichend
> nachstellen können - aber eine getrennte Hardware (Test-PC <->
> Entwicklungs-PC mit Monitoring des Test-PC) erlaubt eine genauere
> Analyse. Es nützt Dir nichts, wenn die virtuelle Maschine den Host-PC
> derart in die Knie zieht, dass der Last-auslösende Prozess auf dem
> Host-PC ebenfalls blockiert wird ...

Nee, CPU-Auslastung kann man so natürlich nicht so leicht testen. Man
kann ein bisschen mit Prozessprioritäten spielen, aber wirklich
belastbare Zahlen kriegt man so nicht.
Ich hatte auch schon den lustigen Fall, dass die VM Fehlverhalten
zeigte, der reale Server nicht. Am Ende stellte sich heraus, dass die VM
mit zuwenig RAM konfiguriert war. (128 MB reichen halt nicht für Apache
plus zweimal php-fcgi; tatsächlich schlug dann aufgrund von thrashing
ein Timeout zu. Andererseits: sollte dieser Effekt bei der realen
Maschine auftreten, weiß ich jetzt etwas genauer, woher es kommen könnte.)

Grüße
Jo

Re: MySQL, ein bischchen php & ärger ...

On 10 Mai, 15:31, Joachim Durchholz wrote:
> Na, jetzt muss ich aber zurückschießen: man merkt, dass Du die Wartung
> von wenigen Servern nicht Dein Spezialgebiet ist.

Ach ne?

> Das Problem sind nicht identische Zustände, sondern ähnliche. Das
> Grundsystem ist in einer halben Stunde überspielt und angepasst

Das war ja die Voraussetzung.

> aber man muss ja regelmäßig Sicherheitsupdates einspielen

... die man zuvor auf der Testmaschine testen sollte! Und dann sollte
es Package-Manager geben ...

> Logs kontrollieren (ja, lässt sich zentralisieren, wenn man eine
> DoS-Schwachstelle aufreißen will...

Die reisst Du genauso auf, wenn Du Dich auf einen Name-Server beziehst
und die Hostnamen nicht nur auf /etc/host auflösen lässt ;-)

Aber, kleiner Tipp am Rande: Zu syslogd gibt es ja auch Alternativen,
die für sowas vorbereitet sind :-)

> Nee, keine Windows-Server. Da wüsste ich nicht mal, wo anfangen beim
> Stopfen der Sicherheitslücken. Das ist schon bei Linux ein unangenehm
> aufwändiges Thema.

??? Irgendwie setzt Du die falsche Software ein ... die Updates für
Apache sind höchst selten, PHP und MySQL sind häufiger, aber auch
nicht die Welt ... OpenSSL/OpenSSH ist auch schon wieder ein paar
Monate nichts ... wenn es natürlich schlampig programmierte PHP-
Anwendungen sind, dann ist's klar, warum's knallt ... aber was muss
man an LAMP so häufig aktualisieren, dass es ein "unangenehm
aufwändiges Thema" wäre?

[..]
> Als ich die Rechneradministration übernommen habe, gab es
> noch gegenseitige Störungsmöglichkeiten...)

Nun, dann sollte das weiter im Bereich Deines Ehrgeizes zu lösen
sein ...

> Aber versuch mal ein problemloses Backup-Programm zu finden. Eines, das
> eine Deltakompression kann, mit LVM-Snapshots zusammenspielt, und die
> Backups den Anwendern einfach als Dateisystemhierarchie präsentiert.

Schonmal auf die Idee gekommen, dass es für verschiedene Zwecke auch
verschiedene Lösungen parallel geben kann? Und für bestimmte Sache
wird es um eine Auftragsarbeit kaum einen Umweg geben: Willst Du einem
Kunden XY einen Snapshot zum Zeitpunkt A zugänglich machen, dann
reicht es nicht, nur die Daten vom Dateisystem zu haben, Du solltest
auch das Abbild der Datenbank zu diesem Zeitpunkt haben.

Allerdings sehe ich da auch nicht die große Hexerei, sowas im
einfachen Rahmen zu handhaben. Snapshots zu genau definierten Zeiten,
die nach gewissen Zeiten automatisch gelöscht werden, und die auf
separaten Partitionen liegen (die im Rahmen des Backups mitgesichert
werden). Ansonsten wäre wohl ein RCS/CVS-System angebracht ...

[Kernel-Parameter]
> Da lass ich auch die Finger von.
> Nicht, weil ich's nicht könnte, sondern weil die paar halben Prozent
> Leistungsgewinn den Zeitaufwand und das Risiko einfach nicht wert sind.

Nun, bei manchen kommerziellen Datenbanklösungen kommst Du nicht drum
herum, bestimmte Einstellungen zu optimieren ... ebenso macht es wenig
Sinn, einen Kernel im Speicher zu haben, der unnötigen Ballast hat
(386/486-Code, 487-Emulation, usw.). Der neue Kernel bietet auch zum
Thema Energiesparen paar nette Features ...

> Aber selbst in dem Fall wäre es sehr fraglich, ob es die Arbeitszeit
> überhaupt wert ist...

Es schadet nicht, erstmal in die Tiefen zu steigen und das System
erstmal um all das zu erleichtern, was man nicht braucht. Auch bei
heute üblichen Linux-Distributionen läuft jede Menge Ballast, den man
problemlos entsorgen kann ... da wird dann auf einmal viel Speicher
frei!

> Die reagieren auf Kerneltuning aber auch nicht so wie der Produktivserver.

Oracle hatte mal bei seinem RDBMS gewissen Erfordernisse, die machten
Änderungen an den Kernel-Parametern unumgänglich ...

BTW: Für weiteres ... bitte Mail! Hier ist es off-topic!

Gruß, Dirk

Re: MySQL, ein bischchen php & ärger ...

Dirk Ohme schrieb:
>> Das Problem sind nicht identische Zustände, sondern ähnliche. Das
>> Grundsystem ist in einer halben Stunde überspielt und angepasst
>
> Das war ja die Voraussetzung.
>
>> aber man muss ja regelmäßig Sicherheitsupdates einspielen
>
> ... die man zuvor auf der Testmaschine testen sollte! Und dann sollte
> es Package-Manager geben ...

Nur: wie testen?
Sowas wie Testcases haben meine Kunden nicht...
.... zum Glück sind Debian-basierte Maschinen da relativ pflegeleicht.
Bei SuSE habe ich schon mehrfach erlebt, dass einem ein
Sicherheitsupdate die Maschine zerschießen konnte, bei Debian scheint
das die absolute Ausnahme zu sein.

>> Logs kontrollieren (ja, lässt sich zentralisieren, wenn man eine
>> DoS-Schwachstelle aufreißen will...
>
> Die reisst Du genauso auf, wenn Du Dich auf einen Name-Server beziehst
> und die Hostnamen nicht nur auf /etc/host auflösen lässt ;-)

Externe Angriffe durch sowas?
Denkbar. Ich wüsste jetzt allerdings nicht, wie.

Lokale Angriffe machen mir weniger Sorgen.

Gut, externe DoS gehen auch über http, das ist weniger das Problem...
die größere Sorge ist eigentlich, dass jemand den Logdatenstrom mit
Falschinformationen vergiftet. Aber vielleicht ist das zu paranoid, das
ist wirklich nicht der wichtigste Angriffsvektor.

> Aber, kleiner Tipp am Rande: Zu syslogd gibt es ja auch Alternativen,
> die für sowas vorbereitet sind :-)

Ich weiß, syslog-ng und Konsorten.
Ist auch schon drauf. Ist nur leider bei Debian nicht der Standard. (Ist
mir unbegreiflich, wie man syslog als Standard in eine Distribution
packen kann - aber ich bin auch kein Maintainer und halt mich da mit
Wertungen raus.)

>> Nee, keine Windows-Server. Da wüsste ich nicht mal, wo anfangen beim
>> Stopfen der Sicherheitslücken. Das ist schon bei Linux ein unangenehm
>> aufwändiges Thema.
>
> ??? Irgendwie setzt Du die falsche Software ein ... die Updates für
> Apache sind höchst selten, PHP und MySQL sind häufiger, aber auch
> nicht die Welt ... OpenSSL/OpenSSH ist auch schon wieder ein paar
> Monate nichts ... wenn es natürlich schlampig programmierte PHP-
> Anwendungen sind, dann ist's klar, warum's knallt ... aber was muss
> man an LAMP so häufig aktualisieren, dass es ein "unangenehm
> aufwändiges Thema" wäre?

Na, so einen Linux-Server sicher zu machen ist immer noch einiges an Arbeit.
In PHP geschriebene Kundenskripte erfordern ein Process Accounting, das
bei den wenigsten Distributionen per Default drin ist. Was ich immer
noch nicht weiß, ist, wie man dafür sorgt, dass auch die CPU- und
RAM-Nutzung für mysql den jeweiligen Kunden-Userids zugeordnet wird.
(Ich bin mir nicht sicher, ob ein separater mysql-daemon für jeden
Nutzer eine gute Idee ist.)
Wär auch mal eine gute Frage hier in der Gruppe, die ist wenigstens
nicht OT...

>> Als ich die Rechneradministration übernommen habe, gab es
>> noch gegenseitige Störungsmöglichkeiten...)
>
> Nun, dann sollte das weiter im Bereich Deines Ehrgeizes zu lösen
> sein ...

Ist es schon längst. suexec+fastcgi+php-fcgi.
War vor zwei Jahren aber noch nicht ohne Selbstkompilation zu lösen.
Sehr ärgerlich, wenn man ein eng begrenztes Zeitbudget hat und darin das
Lesen der Security-Listen und Einspielen von Patches nicht so ohne
weiteres untergebracht kriegt.
Na, mittlerweile übernehmen das zum Glück die Sicherheitsteams der
Distributionen. Ganz zufrieden bin ich mit denen auch nicht, aber von
zwei Servern kriegt man einfach nicht genug Einnahmen, um davon die
Arbeitszeit für eine Vollzeit-Administration zu bezahlen. (Irgendwovon
muss ich meine Brötchen ja auch verdienen.)

>> Aber versuch mal ein problemloses Backup-Programm zu finden. Eines, das
>> eine Deltakompression kann, mit LVM-Snapshots zusammenspielt, und die
>> Backups den Anwendern einfach als Dateisystemhierarchie präsentiert.
>
> Schonmal auf die Idee gekommen, dass es für verschiedene Zwecke auch
> verschiedene Lösungen parallel geben kann? Und für bestimmte Sache
> wird es um eine Auftragsarbeit kaum einen Umweg geben: Willst Du einem
> Kunden XY einen Snapshot zum Zeitpunkt A zugänglich machen, dann
> reicht es nicht, nur die Daten vom Dateisystem zu haben, Du solltest
> auch das Abbild der Datenbank zu diesem Zeitpunkt haben.
>
> Allerdings sehe ich da auch nicht die große Hexerei, sowas im
> einfachen Rahmen zu handhaben. Snapshots zu genau definierten Zeiten,
> die nach gewissen Zeiten automatisch gelöscht werden, und die auf
> separaten Partitionen liegen (die im Rahmen des Backups mitgesichert
> werden).

Die Snapshots sind nicht das Problem.
Obgleich mir beim Lesen der Buglisten von LVM auch schon ganz anders
wurde, die Snapshot-Funktionalität ist wohl noch nicht wirklich
ausgereift (oder war's vor einem Jahr noch nicht, ich hab das Thema
daraufhin erstmal wieder begraben).

> Ansonsten wäre wohl ein RCS/CVS-System angebracht ...

Du machst Witze.
Damit kann man nicht Dutzende von Kundenpräsenzen sichern. Schon gar
nicht, wenn die Kunden jederzeit ihre Dateien umbenennen können...

> [Kernel-Parameter]
>> Da lass ich auch die Finger von.
>> Nicht, weil ich's nicht könnte, sondern weil die paar halben Prozent
>> Leistungsgewinn den Zeitaufwand und das Risiko einfach nicht wert sind.
>
> Nun, bei manchen kommerziellen Datenbanklösungen kommst Du nicht drum
> herum, bestimmte Einstellungen zu optimieren ... ebenso macht es wenig
> Sinn, einen Kernel im Speicher zu haben, der unnötigen Ballast hat
> (386/486-Code, 487-Emulation, usw.). Der neue Kernel bietet auch zum
> Thema Energiesparen paar nette Features ...

Energiesparen ist bei einem Server eher sekundär. Die Platten kann er
bei der derzeitigen Last ohnehin nicht runterfahren, und ob es wirklich
so viel bringt, die CPU zu drosseln...
(Davon abgesehen zahle ich keinen Pfennig weniger, wenn der Server
weniger Strom saugt. Es lohnt also rein finanziell nicht, und ich hab
einfach zu viele andere Baustellen offen, um ein potenziell riskantes
Feature einzubauen.)

>> Aber selbst in dem Fall wäre es sehr fraglich, ob es die Arbeitszeit
>> überhaupt wert ist...
>
> Es schadet nicht, erstmal in die Tiefen zu steigen und das System
> erstmal um all das zu erleichtern, was man nicht braucht. Auch bei
> heute üblichen Linux-Distributionen läuft jede Menge Ballast, den man
> problemlos entsorgen kann ... da wird dann auf einmal viel Speicher
> frei!

Also, vom Selbstkompilieren der Kernels bin ich schon wieder abgekommen.
Irrer Aufwand, aber zumindest bei Debian scheinen sie ausgerechnet beim
Kernel keine Sicherheitsupdates für die Sourcen gemacht zu haben, bei
den fertigkompilierten Kernels schon.
Ist mir unverständlich, aber ... [hatten wir schon]

Und Sicherheit rangiert allemal vor Performance.

Und auch wenn der Kernel einiges an RAM freimacht: soo viel ist es auch
nicht. Der eigentliche Speicherfresser ist immer noch der preforkende
Apache gewesen, da kommts auf ein paar Dutzend MB vom Kernel nicht an
(und so viel lässt sich der Kernel ohnehin nicht abspecken).

Später mal. Wenn die anderen Baustellen und Flaschenhälse aufgeräumt sind.

>> Die reagieren auf Kerneltuning aber auch nicht so wie der Produktivserver.
>
> Oracle hatte mal bei seinem RDBMS gewissen Erfordernisse, die machten
> Änderungen an den Kernel-Parametern unumgänglich ...
>
> BTW: Für weiteres ... bitte Mail! Hier ist es off-topic!

Ich hab doch noch ein bisschen on-topic untergebracht. :-)

Aber Du hast Recht.

Grüße
Jo

Re: MySQL, ein bischchen php & ärger...

Thomas Rachel wrote:
>
>> Ich dachte da eher an "Unix Socket<->IP<->Unix Socket". Quasi sowas
>> wie wie ssh-portforward, nur halt für Unix-Sockets.
>
> Vielleicht hilft Dir socat weiter.

Jep. Gibts sogar in den Ports. Das Problem der Systempflege ist damit
auch quasi gelöst.

cu
Clemens.
--
/"\ http://czauner.onlineloop.com/
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \ AND POSTINGS