Re: [PUG] Neuer Serveradministrator

2008-05-14 Diskussionsfäden oliver . kalk

Martin Schmitt schrieb:

[EMAIL PROTECTED] schrieb:


Aber diese Software wird in 3-5 Monaten abgelöst und deswegen mach ich
mir da keinen Kopp mehr drum.


"Neuer Serveradministrator" manifestiert sich nicht zuletzt auch darin,
daß man die Geschichten hinsichtlich der unmittelbar bevorstehenden
Ablösung der Problemsoftware noch glaubt. ;-)


Ja, der Glaube ist mächtig *hehe
Es werden dann sicherlich weitere/andere Phänomene auftreten und der 
andere Programmieren wird behaupten, dass es nicht an ihm liegt ;-)



kann man vielleicht sagen, das ein anderer Prozessor damit dann besser
zurecht käme oder ist das zu Pauschal gesagt?


Die Lösung liegt im Troubleshooting der Datenbank, und zwar auch dann,
wenn es angeblich nur um 3-5 Monate geht. Der Versuch, Programmierfehler
durch schnellere Hardware zu lösen, führt in die Sackgasse.



Da stimme ich dir zu. Ich habe mich vielleicht auch fehlerhaft 
ausgedrückt. Die Software wird komplett neu geschrieben. Aber ich werde 
mich nun natürlich in der Datenbank festbeissen und mal schauen, ob ich 
irgendetwas herausfinden kann. DBs sind halt auch nicht meine Welt. Aber 
irgendwelche Parameter lassen sich vielleicht herausfinden.


Dann werde ich mich nun einmal in die Datenbank einlesen. Mal schauen, 
was ich da bewerkstelligen kann


danke

ciao
Oliver
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-05-14 Diskussionsfäden Martin Schmitt
[EMAIL PROTECTED] schrieb:

> Aber diese Software wird in 3-5 Monaten abgelöst und deswegen mach ich
> mir da keinen Kopp mehr drum.

"Neuer Serveradministrator" manifestiert sich nicht zuletzt auch darin,
daß man die Geschichten hinsichtlich der unmittelbar bevorstehenden
Ablösung der Problemsoftware noch glaubt. ;-)

> kann man vielleicht sagen, das ein anderer Prozessor damit dann besser
> zurecht käme oder ist das zu Pauschal gesagt?

Die Lösung liegt im Troubleshooting der Datenbank, und zwar auch dann,
wenn es angeblich nur um 3-5 Monate geht. Der Versuch, Programmierfehler
durch schnellere Hardware zu lösen, führt in die Sackgasse.

-martin

-- 
Martin Schmitt / Schmitt Systemberatung / www.scsy.de
--> http://www.pug.org/index.php/Benutzer:Martin <--



signature.asc
Description: OpenPGP digital signature
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-05-14 Diskussionsfäden oliver . kalk

Martin Schmitt schrieb:

[EMAIL PROTECTED] schrieb:


Was meinst du mit Kontext-Switches?


Das ist die Anzahl, wie häufig der Prozessor auf einen anderen Prozeß
umschaltet. Auf einem einem einigermaßen ausgelasteten System kann das
bei einigen Tausend pro Sekunde liegen. Insoweit ist aber logisch, daß
es bei Dir ein sehr niedriger Wert ist, denn Du hast ja nur einen
Prozeß, der die ganze CPU fast allein belegt und kaum Aktivität vieler
verschiedener Prozesse.

Auffallend war auch noch die hohe "Runnable"-Spalte ("r"). Das stützt
die Aussage, daß das System unter hoher Last steht. Bei einem System,
das noch Luft hat, sollte da eigentlich öfter mal eine 0 auftauchen.



Danke für die Erklärung


Meine Einschätzung ist, daß da eine sehr schrottige Applikation auf
einem sehr schrottigen Datenbankschema rumschraddelt. 

Da dies eine selbstprogrammierte PHP-Anwendung ist, kann das durchaus
sein, auch wenn der Programmierer natürlich das Gegenteil beweist.


Beweist er das, oder behauptet er es nur? ;-)


Tja, wie soll man ihm Beweisen, dass es nicht so ist ;-)
Aber diese Software wird in 3-5 Monaten abgelöst und deswegen mach ich 
mir da keinen Kopp mehr drum.
Mir geht es eigentlich nur darum, ob ich diesem Rechner nochmal ein 
wenig unter die Arme greifen kann. Das aufrüsten von 1GB auf 4GB hat 
schon einmal ein wenig gebracht.
Nun gibt es wohl auch einen Cache für die Applikation. Den werde ich mal 
 hochschrauben. Mal schauen, ob das was bringt





Uptime: 415831  Threads: 3  Questions: 10944014  Slow queries: 33144
Opens: 1003  Flush tables: 1  Open tables: 80  Queries per second avg:
26.318


Ich hab hier eine etwas aktivere Datenbank, da hat das OS ein Load
Average von ca. 0.10, wobei der Mittelwert natürlich über die ganze
Laufzeit gerechnet ist. Die vielen Queries, die den Mittelwert heben,
kommen hier nachts bei irgendwelchen Batchjobs zustande:

Uptime: 5530204  Threads: 1  Questions: 832372936  Slow queries: 1861
Opens: 958  Flush tables: 1  Open tables: 256  Queries per second avg:
150.514

Auffallend ist, daß meine Maschine in 2 Monaten 1861 Slow Queries hatte,
und Deine 33144 Slow Queries in ein paar Tagen. Da scheint der Hund
begraben zu sein. Ein Slow Query hat länger als 10 Sekunden
(Defaultwert) gedauert. Macht mindestens 331440 Sekunden für lang
laufende Queries, bei einer Uptime von 415831 Sekunden. Plus etwas mehr
als 10 Millionen Queries, die in weniger als 10 Sekunden (können auch
9.9 Sekunden gewesen sein) durch waren.

Ich muß aber langsam passen, weil ich völliger Datenbank-Laie bin.


Ich zumindest verstanden was du mir erklärt hast :-)


Schau mal die folgenden URLs zum Slow Query Log an, vielleicht ist da
was für Dich dabei:


danke

kann man vielleicht sagen, das ein anderer Prozessor damit dann besser 
zurecht käme oder ist das zu Pauschal gesagt?


ciao
Oliver
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-05-14 Diskussionsfäden Martin Schmitt
[EMAIL PROTECTED] schrieb:

> Was meinst du mit Kontext-Switches?

Das ist die Anzahl, wie häufig der Prozessor auf einen anderen Prozeß
umschaltet. Auf einem einem einigermaßen ausgelasteten System kann das
bei einigen Tausend pro Sekunde liegen. Insoweit ist aber logisch, daß
es bei Dir ein sehr niedriger Wert ist, denn Du hast ja nur einen
Prozeß, der die ganze CPU fast allein belegt und kaum Aktivität vieler
verschiedener Prozesse.

Auffallend war auch noch die hohe "Runnable"-Spalte ("r"). Das stützt
die Aussage, daß das System unter hoher Last steht. Bei einem System,
das noch Luft hat, sollte da eigentlich öfter mal eine 0 auftauchen.

>> Meine Einschätzung ist, daß da eine sehr schrottige Applikation auf
>> einem sehr schrottigen Datenbankschema rumschraddelt. 
> 
> Da dies eine selbstprogrammierte PHP-Anwendung ist, kann das durchaus
> sein, auch wenn der Programmierer natürlich das Gegenteil beweist.

Beweist er das, oder behauptet er es nur? ;-)

> Uptime: 415831  Threads: 3  Questions: 10944014  Slow queries: 33144
> Opens: 1003  Flush tables: 1  Open tables: 80  Queries per second avg:
> 26.318

Ich hab hier eine etwas aktivere Datenbank, da hat das OS ein Load
Average von ca. 0.10, wobei der Mittelwert natürlich über die ganze
Laufzeit gerechnet ist. Die vielen Queries, die den Mittelwert heben,
kommen hier nachts bei irgendwelchen Batchjobs zustande:

Uptime: 5530204  Threads: 1  Questions: 832372936  Slow queries: 1861
Opens: 958  Flush tables: 1  Open tables: 256  Queries per second avg:
150.514

Auffallend ist, daß meine Maschine in 2 Monaten 1861 Slow Queries hatte,
und Deine 33144 Slow Queries in ein paar Tagen. Da scheint der Hund
begraben zu sein. Ein Slow Query hat länger als 10 Sekunden
(Defaultwert) gedauert. Macht mindestens 331440 Sekunden für lang
laufende Queries, bei einer Uptime von 415831 Sekunden. Plus etwas mehr
als 10 Millionen Queries, die in weniger als 10 Sekunden (können auch
9.9 Sekunden gewesen sein) durch waren.

Ich muß aber langsam passen, weil ich völliger Datenbank-Laie bin.

Schau mal die folgenden URLs zum Slow Query Log an, vielleicht ist da
was für Dich dabei:

http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#option_mysqld_long_query_time
http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html

-martin

-- 
Martin Schmitt / Schmitt Systemberatung / www.scsy.de
--> http://www.pug.org/index.php/Benutzer:Martin <--



signature.asc
Description: OpenPGP digital signature
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-05-14 Diskussionsfäden oliver . kalk

Martin Schmitt schrieb:

[EMAIL PROTECTED] schrieb:


USER  PID %CPU %MEM   VSZ  RSS TTY  STAT START   TIME COMMAND
mysql 832 65.2  1.7 157028 71152 ?   SMay09 4440:01 /usr/sbin/mysqld


MySQL mit kaum Speicherverbrauch aber eklatant hoher CPU-Auslastung.


Manchmal sieht man den Wald vor lauter Bäume nicht. Ich achte nur auf 
RAM und übersehe die CPU *grrr



 total   used   free sharedbuffers cached
Mem: 40634963742568 320928  0 2382802730100
-/+ buffers/cache:   7741883289308
Swap:1004052 121004040


Das heißt, daß Webserver, Datenbank und was sonst noch alles läuft,
gerade mal 774 MB belegen. Das System hat definitiv kein Speicherproblem.


Ok, dann habe ich das also falsch gelesen. Es ist also noch genug frei.


procsmemory  swap  io system cpu
r b swpd  free  buff cachesi   sobibo   incs us sy id wa
6 0  12 320580 240320 2732840  001421   9933 78 11 11  1
5 0  12 320580 240320 2732848  00 0 0  205   788 95  5  0  0
4 0  12 320588 240320 2732876  00 0 0  301   561 90 10  0  0
5 0  12 320588 240324 2732880  00 0   304  192   507 89 11  0  0
6 0  12 320104 240324 2732880  00 0 0  188   445 92  8  0  0
8 0  12 319816 240328 2733140  00 0 0  179   928 90 10  0  0
7 0  12 313000 240332 2739928  00 0 0  190   757 83 17  0  0
7 0  12 302292 240344 2748588  00 0 0  217   705 90 10  0  0
7 0  12 318256 240364 2732916  00 0   272  241   652 80 20  0  0
6 0  12 318256 240364 2732924  00 0 0  241   459 93  7  0  0


Dazu passend keine Swap-Aktivität. Sehr wenig I/O, kein Engpaß
erkennbar. Mich wundern etwas die wenigen Kontext-Switches auf einer
Maschine, die so unter Last stehen soll.


Was meinst du mit Kontext-Switches?


Meine Einschätzung ist, daß da eine sehr schrottige Applikation auf
einem sehr schrottigen Datenbankschema rumschraddelt. 


Da dies eine selbstprogrammierte PHP-Anwendung ist, kann das durchaus 
sein, auch wenn der Programmierer natürlich das Gegenteil beweist.



Was sagt
"mysqladmin status"? Kommt bei "mysqladmin processlist" was auffälliges
raus?


status

Uptime: 415831  Threads: 3  Questions: 10944014  Slow queries: 33144 
Opens: 1003  Flush tables: 1  Open tables: 80  Queries per second avg: 
26.318



processlist

++--+---+-+-+--+---+--+
| Id | User | Host  | db  | Command | Time | State | Info 
  |

++--+---+-+-+--+---+--+
| 429483 | root | localhost | keyhelp | Sleep   | 14   |   | 
  |

| 429494 | root | localhost | | Query   | 0   ||show processlist |

ciao
Oliver

-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-05-14 Diskussionsfäden oliver . kalk

Christian Schneider schrieb:

[...]


Mit free wird immer angezeigt, das 3,8GB bis 3,9GB Speicher belegt
sind.

Auf einem gesunden UNIX-System ist der Speicher immer randvoll.
Zeig mal die Ausgabe von "free" her.

total   usedfreesharedbuffers   cached
Mem:40634963742568 320928  0   238280   2730100
-/+ buffers/cache:  7741883289308 
Swap:   1004052 121004040


Ich kann mich natürlich irren, aber für mich sieht das so aus, als wären 
~770 MB RAM belegt und ~3,2 GB frei. Dieser "freie" Speicher wird wenn 
nicht benötigt, für Cache und Puffer verwendet. Die Zeile 
-/+ buffers/cache:  7741883289308
gibt die "bereinigten" Werte an, in der Zeile obendrüber sieht man die 
genaue Verteilung.


Hmm, dann werde ich mich nochmal durch die manpage durchwühlen. 
Möglicherweise interpretiere ich die Ausgabe von free falsch ;-(


Danke schonmal für den Hinweis

Ich denke nicht, das es am RAM scheitert. Ist die Maschine 
Prozessormässig vielleicht einfach am Ende?
Das wäre die nächste Möglichkeit. Dann muss die Maschine die nächsten 
4-5 Monate durchhalten, bis ne neue Hardware kommt.
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-05-14 Diskussionsfäden Martin Schmitt
[EMAIL PROTECTED] schrieb:

> USER  PID %CPU %MEM   VSZ  RSS TTY  STAT START   TIME COMMAND
> mysql 832 65.2  1.7 157028 71152 ?   SMay09 4440:01 /usr/sbin/mysqld

MySQL mit kaum Speicherverbrauch aber eklatant hoher CPU-Auslastung.

>  total   used   free sharedbuffers cached
> Mem: 40634963742568 320928  0 2382802730100
> -/+ buffers/cache:   7741883289308
> Swap:1004052 121004040

Das heißt, daß Webserver, Datenbank und was sonst noch alles läuft,
gerade mal 774 MB belegen. Das System hat definitiv kein Speicherproblem.

> procsmemory  swap  io system cpu
> r b swpd  free  buff cachesi   sobibo   incs us sy id wa
> 6 0  12 320580 240320 2732840  001421   9933 78 11 11  1
> 5 0  12 320580 240320 2732848  00 0 0  205   788 95  5  0  0
> 4 0  12 320588 240320 2732876  00 0 0  301   561 90 10  0  0
> 5 0  12 320588 240324 2732880  00 0   304  192   507 89 11  0  0
> 6 0  12 320104 240324 2732880  00 0 0  188   445 92  8  0  0
> 8 0  12 319816 240328 2733140  00 0 0  179   928 90 10  0  0
> 7 0  12 313000 240332 2739928  00 0 0  190   757 83 17  0  0
> 7 0  12 302292 240344 2748588  00 0 0  217   705 90 10  0  0
> 7 0  12 318256 240364 2732916  00 0   272  241   652 80 20  0  0
> 6 0  12 318256 240364 2732924  00 0 0  241   459 93  7  0  0

Dazu passend keine Swap-Aktivität. Sehr wenig I/O, kein Engpaß
erkennbar. Mich wundern etwas die wenigen Kontext-Switches auf einer
Maschine, die so unter Last stehen soll.

Meine Einschätzung ist, daß da eine sehr schrottige Applikation auf
einem sehr schrottigen Datenbankschema rumschraddelt. Was sagt
"mysqladmin status"? Kommt bei "mysqladmin processlist" was auffälliges
raus?

-martin

-- 
Martin Schmitt / Schmitt Systemberatung / www.scsy.de
--> http://www.pug.org/index.php/Benutzer:Martin <--



signature.asc
Description: OpenPGP digital signature
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-05-14 Diskussionsfäden Christian Schneider
Am Mittwoch, 14. Mai 2008 10:11 schrieb [EMAIL PROTECTED]:
> Martin Schmitt schrieb:
> > [EMAIL PROTECTED] schrieb:

[...]

> >> Mit free wird immer angezeigt, das 3,8GB bis 3,9GB Speicher belegt
> >> sind.
> >
> > Auf einem gesunden UNIX-System ist der Speicher immer randvoll.
> > Zeig mal die Ausgabe von "free" her.
>
> total   usedfreesharedbuffers   cached
> Mem:40634963742568 320928  0   238280   2730100
> -/+ buffers/cache:  7741883289308 
> Swap:   1004052 121004040

Ich kann mich natürlich irren, aber für mich sieht das so aus, als wären 
~770 MB RAM belegt und ~3,2 GB frei. Dieser "freie" Speicher wird wenn 
nicht benötigt, für Cache und Puffer verwendet. Die Zeile 
-/+ buffers/cache:  7741883289308
gibt die "bereinigten" Werte an, in der Zeile obendrüber sieht man die 
genaue Verteilung.

Ich denke nicht, das es am RAM scheitert. Ist die Maschine 
Prozessormässig vielleicht einfach am Ende?

Viele Grüße,
Christian
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-05-14 Diskussionsfäden oliver . kalk

Martin Schmitt schrieb:

[EMAIL PROTECTED] schrieb:

Doch nun schnappt sich wohl der SQL den gesamten Speicher. 

 
Tut er's oder tut er es nicht? "ps auxk vsz" zeigt Dir die Prozesse nach 
Speicherbelegung sortiert an.


Da diese Paramter bei mir nicht so wollten, habe ich die MAN-Page zu PS 
gelesen. Auf Deutsche übersetzt ;-)


Das kommt dann zu dem folgenden Parameter:
--cumulative Daten von toten Kindern einbeziehen (als Summe zusammen 
mit den Eltern)


Jaja, es gibt Dinge, die sollte man nicht übersetzten ;-)

Hier mal die Ausgabe von ps aux... sobald ich die anderen Parameter 
gefunden habe, kommt auch eine sortierte Auflistung (RH Enterprise 3)


USER  PID %CPU %MEM   VSZ  RSS TTY  STAT START   TIME COMMAND
root1  0.0  0.0  1524  500 ?SMay09   0:06 init [3]
root2  0.0  0.0 00 ?SW   May09   0:00 [migration/0]
root3  0.0  0.0 00 ?SW   May09   0:11 [keventd]
root4  0.0  0.0 00 ?SW   May09   0:01 [kapmd]
root5  0.0  0.0 00 ?SWN  May09   0:00 [ksoftirqd/0]
root8  0.0  0.0 00 ?SW   May09   0:04 [bdflush]
root6  0.0  0.0 00 ?SW   May09   0:13 [kswapd]
root7  0.0  0.0 00 ?SW   May09   0:19 [kscand]
root9  0.0  0.0 00 ?SW   May09   0:04 [kupdated]
root   10  0.0  0.0 00 ?SW   May09   0:00 [mdrecoveryd]
root   14  0.0  0.0 00 ?SW   May09   0:48 [kjournald]
root  334  0.0  0.0 00 ?SW   May09   1:13 [kjournald]
root  335  0.0  0.0 00 ?SW   May09   0:37 [kjournald]
root  629  0.0  0.0  1588  584 ?SMay09   0:02 syslogd -m 0
root  633  0.0  0.0  1540  468 ?SMay09   0:00 klogd -x
named 653  0.0  0.1 37868 4620 ?SMay09   0:37 /usr/sbin/named -
rpc   677  0.0  0.0  1660  576 ?SMay09   0:00 portmap
rpcuser 696  0.0  0.0  1676  712 ?SMay09   0:00 rpc.statd
root  732  0.0  0.0  1504  512 ? SMay09   0:00 /usr/sbin/apmd -p
root  772  0.0  0.0  3668 1556 ? SMay09   0:08 /usr/sbin/sshd
root  783  0.0  0.0  5356 1056 ? SMay09   0:00 /bin/bash /sbin/s
root  793  0.0  0.0  2132  840 ? SMay09   0:01 xinetd -stayalive
root  802  0.0  0.0  1788  512 ? SMay09   0:00 /usr/sbin/vsftpd
root  811  0.0  0.0  5356 1184 ?SMay09   0:00 /bin/sh /usr/bin/
mysql 832 65.2  1.7 157028 71152 ?   SMay09 4440:01 /usr/sbin/mysqld
root  861  0.0  0.0  6112 2556 ?   SMay09   0:09 sendmail: accepti
smmsp 870  0.0  0.0  6000 2280 ?   SMay09   0:00 sendmail: Queue r
root  881  0.0  0.7 35896 30652 ?  SMay09   0:50 /usr/bin/spamd -d
root  894  0.0  0.0  5584 1016 ?SMay09   0:00 crond
xfs   917  0.0  0.0  5504 3184 ? SMay09   0:00 xfs -droppriv -da
root  927  0.0  0.2 90176 11004 ?SMay09   0:22 /usr/sbin/httpd -
daemon 935  0.0  0.0  1588  568 ?   SMay09   0:00 /usr/sbin/atd
root  990  0.0  0.0  1596  412 ? SMay09   0:00 mdadm --monitor -
root  1003  0.0  0.2 12148 12144 ? SL   May09   0:01 mdmpd
root  1011  0.0  0.0  2192  912 ?SMay09   0:00 /bin/su -
root  1012  0.0  0.0  1504  428 tty2 SMay09   0:00 /sbin/mingetty tt
root  1013  0.0  0.0  1504  428 tty3 SMay09   0:00 /sbin/mingetty tt
root  1014  0.0  0.0  1504  428 tty4 SMay09   0:00 /sbin/mingetty tt
root  1015  0.0  0.0  1504  428 tty5 SMay09   0:00 /sbin/mingetty tt
root  1016  0.0  0.0  1504  428 tty6 SMay09   0:00 /sbin/mingetty tt
root  1017  0.0  0.0  2180  976 ?SMay09   0:00 /bin/sh /home/adm
root  1019  0.0  0.0  5524 1412 ?SMay09   0:00 -bash
root  1074  0.0  0.7 35896 30660 ?   SMay09   0:00 spamd child
root  1075  0.0  0.7 35896 30660 ?S   May09   0:00 spamd child
root  11058  0.0  0.0  6892 2064 ?S   May11   0:00 /usr/bin/perl /sb
root  11059  0.0  0.0  4984  592 ?S   May11   0:04 /usr/bin/tail --f
nobody 11564  0.0  0.2 90176 10920 ?  S   May11   0:00 /usr/sbin/fcgi- -
root  10185  0.0  0.0  2388  704 ?S   03:21   0:00 /usr/sbin/saslaut
root  10186  0.0  0.0  2388  704 ?S   03:21   0:00 /usr/sbin/saslaut
root 10187  0.0  0.0  2388  704 ? S   03:21   0:00 /usr/sbin/saslaut
root 10190  0.0  0.0  2388  704 ? S   03:21   0:00 /usr/sbin/saslaut
root 10191  0.0  0.0  2388  704 ? S   03:21   0:00 /usr/sbin/saslaut
nobody   15502  0.3  0.6 104452 24804 ? S 08:33   0:09 /usr/sbin/httpd -
nobody   15962  1.5  0.4 96240 17680 ? S  08:53   0:29 /usr/sbin/httpd -
nobody   16010  0.7  0.4 96132 17668 ? S  08:56   0:12 /usr/sbin/httpd -
nobody   16044  1.1  0.4 96188 17712 ? S  08:58   0:18 /usr/sbin/httpd -
nobody   16172  0.7  0.4 96040 17476 ? S  09:03   0:09 /usr/sbin/httpd -
nobody   16202  1.5  0.4 96376 17804 ? S  09:05   0:18 /usr/sbin/httpd -
nobody   16203  1.5  0.4 96560 17992 ? S  09:05   0:19 /usr/sbin/httpd -
nobody   16204  0.6  0.4 95912 17316 ? S  09:05   0:07 /usr/sbin/httpd -
nobody   16275  0.5  0.4 95852 17276 ? S  09:

Re: [PUG] Neuer Serveradministrator

2008-05-13 Diskussionsfäden Martin Schmitt

[EMAIL PROTECTED] schrieb:

Doch nun schnappt sich wohl der SQL den gesamten Speicher. 

 
Tut er's oder tut er es nicht? "ps auxk vsz" zeigt Dir die Prozesse nach 
Speicherbelegung sortiert an.



Mit free wird immer angezeigt, das 3,8GB bis 3,9GB Speicher belegt sind.


Auf einem gesunden UNIX-System ist der Speicher immer randvoll. Zeig mal 
die Ausgabe von "free" her.


In dem Moment, wo der Server richtig langsam ist, würde mich auch mal 
die Ausgabe von "vmstat 1 10" interessieren.


-martin



signature.asc
Description: OpenPGP digital signature
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-05-13 Diskussionsfäden oliver . kalk
Danke für die Tipps. Soweit ich es beurteilen kann, sieht das alles 
ziemlich gut aus mit den Servern. Konnte noch nichts auffälliges 
erkennen. Dazu fehlt mir dann aber auch die Erfahrung im Linux-Umfeld, 
aber das kommst schon.


Jetzt was anderes:
In einem der Server sind nun 4 GB Ram eingebaut, weil die Ansprechzeiten 
des Webzugriffes beim Upload der Daten... ich fang lieber mal von der 
anderen Seite an...


Es handelt sich hier um einen Server mit einem Marktplatz im Internet. 
Er basiert auf Apachen, MySQL und PHP (LAMP). Nun habe ich als ersten 
Tipp für eine Verbesserung der Ansprechzeiten "Add more RAM" gesagt. 
Nach langem hin und her mit dem Provider, hat sich dieser nun 
breitschlagen lassen und die 1GB auf 4GB aufgerüstet. Doch nun schnappt 
sich wohl der SQL den gesamten Speicher. Mit free wird immer angezeigt, 
das 3,8GB bis 3,9GB Speicher belegt sind.
Nun ist mein Wissen in dieser Welt (LAMP) nicht sehr ergiebig. Kann man 
dem mysql sagen dass er nicht so viele Instanzen öffnen soll wie ich es 
beim Apachen machen kann? Wenn ich top aufrufe, dann sehe ich sehr viel 
mysqld Prozesse.
Oder könnte das auch was anderes sein - ich weis, eure Glaskugel ist im 
Schrank unter ner Decke versteckt, aber mir fallen nicht die richtigen 
Fragen ein.
Ich liefere auch gerne die Infos von top und ps und was man da noch 
brauchen kann um etwas heraus zu finden.
Nur wird mit dem aufgebrauchten RAM der Server eben langsamer und das 
ist nicht gut :-)


Vielen Dank für jeden Tipp

--

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-29 Diskussionsfäden Martin Schmitt

Stefan Jakob schrieb:

Better have a FULL-Backup!!! Damit wie schon vorgeschlagen versuchen den 
Server zu clonen und mit dem Clone einen "Takeover" zu planen und 
auszuprobieren. Meiner Erfahrung nach fliegt man ohne eine Testumgebung 
und ein gutes Backup schnell auf die Nase...


Wobei die Definition von "Gutes Backup" nicht für jeden gleich aussieht.

-martin



signature.asc
Description: OpenPGP digital signature
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-29 Diskussionsfäden Stefan Jakob
Was ich dazu in die Runde werfen mag:

Better have a FULL-Backup!!! Damit wie schon vorgeschlagen versuchen den
Server zu clonen und mit dem Clone einen "Takeover" zu planen und
auszuprobieren. Meiner Erfahrung nach fliegt man ohne eine Testumgebung und
ein gutes Backup schnell auf die Nase...

Grüße und gutes Gelingen!

Stefan
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-23 Diskussionsfäden oliver . kalk

Martin Schmitt schrieb:

[EMAIL PROTECTED] schrieb:


Doku? Die Doku ist derjenige der das bisher machte und nun keine
Lust/Zeit mehr hat. Da es sich hierbei um mein Hobby - dem Comicsammeln
- handelt, wurde ich gefragt, ob ich mir das antun mag ;-)


RHEL3 auf einer Hobbykiste?!? Hat das System denn überhaupt jemals
irgendwelche Updates zu sehen bekommen?


Hey Martin

die Teile stehen bei nem Povider (Keyweb) und sind schon für nen 
Professionellen Einsatz gedacht. Mit Hobby meinte ich nur, dass es meine 
Hobby ist, was mich mit diesen Webseiten verbindet. Die Seiten sind sehr 
groß und stark besucht. ;-)


ciao
Oliver
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-23 Diskussionsfäden Christian Felsing
Irgendein Update bestimmt, entweder die RH Updates vom Sysadmin 
installiert, oder ein Root-Kit von irgendjemandem...


Grüße
Christian

Martin Schmitt schrieb:

RHEL3 auf einer Hobbykiste?!? Hat das System denn überhaupt jemals
irgendwelche Updates zu sehen bekommen?


-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-23 Diskussionsfäden Martin Schmitt
[EMAIL PROTECTED] schrieb:

> Doku? Die Doku ist derjenige der das bisher machte und nun keine
> Lust/Zeit mehr hat. Da es sich hierbei um mein Hobby - dem Comicsammeln
> - handelt, wurde ich gefragt, ob ich mir das antun mag ;-)

RHEL3 auf einer Hobbykiste?!? Hat das System denn überhaupt jemals
irgendwelche Updates zu sehen bekommen?

-martin

-- 
Martin Schmitt / Schmitt Systemberatung / www.scsy.de
--> http://www.pug.org/index.php/Benutzer:Martin <--



signature.asc
Description: OpenPGP digital signature
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-23 Diskussionsfäden oliver . kalk

Christian Felsing schrieb:
Kleiner Tip am Rande. Versuche einfach mit der vorhandenen Doku ein 
Desaster-Recovery auf einem PC. Sollte da eine voll funktionsfähige 
Kopie der Produktionsserver herauskommen, dann kann man die vorhandene 
Doku als "brauchbar" einstufen.


Doku? Die Doku ist derjenige der das bisher machte und nun keine 
Lust/Zeit mehr hat. Da es sich hierbei um mein Hobby - dem Comicsammeln 
- handelt, wurde ich gefragt, ob ich mir das antun mag ;-)


Ich werde wohl ne Doku erstellen, damit dort ein DR behandelt werden 
kann. Denn von einem DR-Szenarion oder Plan habe ich da noch nichts 
gesehen *g




Die weiteren Punkte hat ja Martin in seiner Mail schon genannt.

Grüße
Christian

[EMAIL PROTECTED] schrieb:
Wie geht ihr da nun vor um erst einmal den Grundzustand der Server zu 
testen und zu dokumentieren?




--

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-23 Diskussionsfäden Christian Felsing
Kleiner Tip am Rande. Versuche einfach mit der vorhandenen Doku ein 
Desaster-Recovery auf einem PC. Sollte da eine voll funktionsfähige 
Kopie der Produktionsserver herauskommen, dann kann man die vorhandene 
Doku als "brauchbar" einstufen.


Die weiteren Punkte hat ja Martin in seiner Mail schon genannt.

Grüße
Christian

[EMAIL PROTECTED] schrieb:
Wie geht ihr da nun vor um erst einmal den Grundzustand der Server zu 
testen und zu dokumentieren?


--

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-23 Diskussionsfäden oliver . kalk

[EMAIL PROTECTED] schrieb:

Danke für den Input. Da stehen mir ja ein paar Tage ins Haus, naja so 
lerne ich auch mal RH kennen :-)


ciao

--

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-23 Diskussionsfäden Martin Schmitt
[EMAIL PROTECTED] schrieb:

> Wie geht ihr da nun vor um erst einmal den Grundzustand der Server zu
> testen und zu dokumentieren?

Root-Zugang für evtl. bisher beteiligte Dritte sperren.

Funktionsfähige unbekannte Logins finden und ggf. sperren.

Rausfinden, welche Distribution läuft.

Prüfen, ob wichtige Updates fehlen und in Absprache mit dem Kunden
nachziehen.

Prüfen, welche Dienste laufen und unbenötigte Dienste in Absprache mit
dem Kunden deaktivieren.

Prüfen, ob ein funktionierendes Monitoring z.B. für Plattenfüllstände
existiert.

Falls RAID, prüfen, ob die Redundanz noch gegeben ist.

Prüfen, ob irgendwelche wilden Admin-User fürs System und die Datenbank
existieren.

Prüfen, welche Dienste per Internet erreichbar sind.

> *Protokolle checken

Hm. Naja. Die rückwirkende Betrachtung von Protokollen wird IMHO
überbewertet. Aber man könnte schauen, ob der Server eine
funktionierende Logrotation hat, oder ob der alte Admin da jeden Montag
von Hand an irgendwelchen Applikationslogs rumgeschraubt hat.

> *Allgemeine Konfigurationen checken (was sollte man da alles checken -
> ntp, dns, samba, nfs fällt mir da mal direkt ein)

Samba, NFS und RPC haben am Internet nichts zu suchen. DNS wird i.d.R.
nicht laufen, aber man sollte sicherstellen, daß da kein
fehlkonfigurierter Nameserver (Stichwort: Authoritativ und Rekursiv) am
Internet rumhängt.

> *Backupkonzept prüfen und überdenken (die werden gerade mal per rsync
> von einem auf den anderen Server gesichert) Da halte ich nicht sooo viel
> davon

Heißt auf deutsch: Du kannst das noch ändern, wenn alles andere erledigt
ist.

> *Installiert ist meines Wissens nach ein RH 3 Enterprise auf den
> Servern. Sie sollen gegen Ende des Jahres abgelöst werden, dabei
> kann/soll auch das OS getauscht werden (neues RH, Suse oder Debian)

RHEL3 wird noch ein paar Jahre lang mit Updates versorgt, also keine
Panik. :-)

-martin

-- 
Martin Schmitt / Schmitt Systemberatung / www.scsy.de
--> http://www.pug.org/index.php/Benutzer:Martin <--



signature.asc
Description: OpenPGP digital signature
-- 

PUG - Penguin User Group Wiesbaden - http://www.pug.org


Re: [PUG] Neuer Serveradministrator

2008-04-23 Diskussionsfäden Dieter Ries

[EMAIL PROTECTED] schrieb:

Hallo

mal ne allgemeine Frage zu Tipps und Vorgenhensweise - eher ein 
Erfahrungsaustausch.

Mir wurde die Administrierung 2 Linux Server übertragen - besser, ich wurde 
gefragt, ob ich das mal machen könnte.

Nun sind dies zwei Webserver größerer Webseiten im Internet. Es geht hierbei vornehmlich um die Administrierung der 
Server nicht der Web-Server.


Wie geht ihr da nun vor um erst einmal den Grundzustand der Server zu testen 
und zu dokumentieren?


Erst mal schaun, wie die IPTABLES Konfiguration aussieht. Dann würde ich 
schauen, ob nicht irgendwo schon Scripte für Standardaufgaben wie User 
hinzufügen etc. rumliegen.




Die Server stehen bei einem Provider und ich habe da root-Zugriff drauf.

*Protokolle checken


Ob dir die Protokolle was nützen, bevor du die Konfiguration kennst, 
weiss ich nicht.




*IP-Konfiguration aufnehmen

*Allgemeine Konfigurationen checken (was sollte man da alles checken - ntp, dns, samba, nfs fällt mir da mal direkt 
ein)


sshd, ftp, apache, php etc.



*Backupkonzept prüfen und überdenken (die werden gerade mal per rsync von einem auf den anderen Server gesichert) 
Da halte ich nicht sooo viel davon


*Installiert ist meines Wissens nach ein RH 3 Enterprise auf den Servern. Sie sollen gegen Ende des Jahres abgelöst 
werden, dabei kann/soll auch das OS getauscht werden (neues RH, Suse oder Debian)


Ich möchte keine Anleitung sondern nur Tipps, was ich noch aufnehmen sollte, bevor ich anfange Tipps zur 
Optimierung geben zu können.


Danke

ciao
Oliver



cu
Dieter
--

PUG - Penguin User Group Wiesbaden - http://www.pug.org