Wednesday, May 22nd 2013, 11:21am UTC+2

You are not logged in.

  • Login
  • Register

ndo2db - mehrere connections zur datenbank einstellen?

Dear visitor, welcome to Monitoring-Portal.
Although this is a german monitoring forum, please don't hesitate to post in English. Nearly everybody here understands you and will answer in English as well.
If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form to register here or read more information about the registration process. If you are already registered, please login here.

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

1

Thursday, March 5th 2009, 2:20pm

ndo2db - mehrere connections zur datenbank einstellen?

hallo,

ist es moeglich das ndo2db mehrere connections gleichzeitig zur MySQL DB aufmacht? wenn ich in PHPMyAdmin schaue dann ist dort immer nur ein process zu finden. Ich habe aber 2 Quad-Core CPU's drin und genug Power das ndo2db ein wenig schneller arbeiten koennte.
Kann ich das irgendwo einstellen oder muss ich dazu den Source Code abaendern (meine rudimentaeren C Kenntnisse reichen da nicht wirklich aus selbst auf die Loesung zu kommen).

Problem ist das Nagios derzeit ca. 15-30 Minuten braucht bis es gestartet ist. In der Zeit wird die Datenbank von NDO vollgeschrieben (ich habe es schon auf das Noetigste reduziert ueber die Eventbroker Settings). Das ist einfach sehr lange und in dieser Zeit werden keinerlei Checks ausgefuehrt und keine Mails versandt.

Die einzelnen Queries sind sehr flott, aber durch die Masse scheint es wohl trotzdem so lange zu dauern. Ich stelle mir das so vor wie wenn ich per FTP 10 000 kleine Dateien uebertragen will, das dauert auch ewig wenn ich nur eine Connection benutze. Wenn ich die Dateien in ein Archiv packen wuerde, dann waere es auch mit einer Connection sehr flott. Soll ich vielleicht statt einem Unix Socket mal ein TCP Socket ausprobieren oder gar ein file und dann file2ndo benutzen um die Daten in MySQL zu bekommen?

Bin echt fuer jede Hilfe dankbar denn derzeit hab ich nur ca. 1/5 der Services eingetragen, wenn ich noch mehr hinzufuege wird Nagios in Zukunft wohl mehrere Stunden zum starten benoetigen.

Andurin

Unregistered

2

Thursday, March 5th 2009, 2:36pm

Hi,

mehrere Verbindungen einer NDO2DB Instanz sind derzeit nicht vorgesehen.

Gruß
Hendrik

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

3

Thursday, March 5th 2009, 2:39pm

Danke fuer die schnelle Antwort, dann muss ich mir echt was anderes ueberlegen.

Andurin

Unregistered

4

Thursday, March 5th 2009, 2:41pm

Quoted from "falc410"

Problem ist das Nagios derzeit ca. 15-30 Minuten braucht bis es gestartet ist. In der Zeit wird die Datenbank von NDO vollgeschrieben (ich habe es schon auf das Noetigste reduziert ueber die Eventbroker Settings).


Denk da noch einmal drüber nach...
Ich denke ich hab ein paar mehr Services und brauche keine 15-30 Minuten... hängt aber auch davon ab, was du als notwendig ansiehst.

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

5

Thursday, March 5th 2009, 2:47pm

Ich habe nur die minimalen Settings fuer NagVis drin (entnommen aus Wolfgang seinem Buch, S. 385 / 386):

program_state
downtime_data
status_data
retention_data
acknowledgement_data
= 102913

Mehr kann ich nicht wegschneiden da das die Daten sind die ich auch fuer meine anderen Zwecke benoetige.

Die Daten an sich sind auch nicht viel, das Problem ist halt nur das es beim starten ewig dauert da es eben nur eine Connection zur DB gibt. Jede Query an sich geht sehr schnell von statten, aber es sind halt trotzdem jede Menge.
Bei fast 400 Services dauert es 15 Minuten bis das Webinterface von Nagios verfuegbar ist (vorher steht da das der Process nicht laufen wuerde, die tolle WHOOPS Seite) und dann nochmal ca. 15 Minuten bis die ersten Checks ausgefuehrt werden. Das ist einfach zu lange.
Die Kiste hat 2 Quad-Core AMD Opteron mit jeweils glaube 2 Ghz, 8 GB RAM und liegt auf schnellen SAS Platten (allerdings auf einer DRBD Partition, aber die langweilt sich auch nur, genauso wie das restliche System und der MySQL Server, 99% idle, das System dreht Daeumchen die ganze Zeit).

little

Professional

Posts: 791

Birthday: Nov 26th 1975 (37)

Gender: male

Location: Mainburg

Occupation: PDM-Consultant, IT-Specialist

Number of monitoring servers: 3

Nagios Version: 3.2.0/3.2.1/3.2.2

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~200

Number of services: ~1800

OS: Linux, AIX, HP-UX, Windows

Plugin Version: 1.4.14/1.4.15

NagVis Version: 1.4-nightly/1.5-nightly

NDO Version: 1.4b9

Other Addons: NRPE, PNP,NSClient++,DokuWiki,NagiosBPV, MKLivestatus, Thruk

6

Thursday, March 5th 2009, 2:53pm

Hast du die updates für die NDOUtils auch eingespielt?
Was bei mir noch geholfen hat, war, daß ich den Tabellentyp von InnoDB auf MyISAM umgestellt habe.

Little
OMD - Open Monitoring Distribution

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

7

Thursday, March 5th 2009, 2:59pm

Ich habe es noch auf InnoDB belassen da ich auch nicht unbedingt davon ausgehe das es ein Performanceproblem ist. Habe die Datenbank auch noch nicht optimiert im Sinne von Indexe hinzufuegen.

Was fuer Updates? Ist 1.4.7b nicht das letzte release?

little

Professional

Posts: 791

Birthday: Nov 26th 1975 (37)

Gender: male

Location: Mainburg

Occupation: PDM-Consultant, IT-Specialist

Number of monitoring servers: 3

Nagios Version: 3.2.0/3.2.1/3.2.2

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: ~200

Number of services: ~1800

OS: Linux, AIX, HP-UX, Windows

Plugin Version: 1.4.14/1.4.15

NagVis Version: 1.4-nightly/1.5-nightly

NDO Version: 1.4b9

Other Addons: NRPE, PNP,NSClient++,DokuWiki,NagiosBPV, MKLivestatus, Thruk

8

Thursday, March 5th 2009, 3:36pm

Es gibt ein SQL-Script, das noch Modifikationen in der DB macht.

MySQL queries

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

-- BEGIN 1.4b7 MODS

ALTER TABLE `nagios_configfilevariables` DROP INDEX `instance_id`;
ALTER TABLE `nagios_configfilevariables` ADD INDEX ( `instance_id` , `configfile_id` ) ;

ALTER TABLE `nagios_timedeventqueue` ADD INDEX ( `instance_id` ) ;

ALTER TABLE `nagios_statehistory` ADD INDEX ( `instance_id` , `object_id` ) ;

ALTER TABLE `nagios_servicestatus` ADD INDEX ( `instance_id` , `service_object_id` ) ;

ALTER TABLE `nagios_processevents` ADD INDEX ( `instance_id` , `event_type` ) ;

ALTER TABLE `nagios_logentries` ADD INDEX ( `instance_id` ) ;

ALTER TABLE `nagios_hoststatus` ADD INDEX ( `instance_id` , `host_object_id` ) ;

ALTER TABLE `nagios_flappinghistory` ADD INDEX ( `instance_id` , `object_id` ) ;

ALTER TABLE `nagios_externalcommands` ADD INDEX ( `instance_id` ) ;

ALTER TABLE `nagios_customvariablestatus` ADD INDEX ( `instance_id` ) ;

ALTER TABLE `nagios_contactstatus` ADD INDEX ( `instance_id` ) ;

ALTER TABLE `nagios_conninfo` ADD INDEX ( `instance_id` ) ;

ALTER TABLE `nagios_acknowledgements` ADD INDEX ( `instance_id` , `object_id` ) ;

ALTER TABLE `nagios_objects` ADD INDEX ( `instance_id` ) ;

ALTER TABLE `nagios_logentries` ADD INDEX ( `logentry_time` ) ;

ALTER TABLE `nagios_commenthistory` CHANGE `comment_data` `comment_data` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_comments` CHANGE `comment_data` `comment_data` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_downtimehistory` CHANGE `comment_data` `comment_data` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_externalcommands` CHANGE `command_args` `command_args` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_hostchecks` CHANGE `output` `output` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;
ALTER TABLE `nagios_hostchecks` CHANGE `perfdata` `perfdata` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_hoststatus` CHANGE `output` `output` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;
ALTER TABLE `nagios_hoststatus` CHANGE `perfdata` `perfdata` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_logentries` CHANGE `logentry_data` `logentry_data` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_scheduleddowntime` CHANGE `comment_data` `comment_data` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_servicechecks` CHANGE `output` `output` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;
ALTER TABLE `nagios_servicechecks` CHANGE `perfdata` `perfdata` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_servicestatus` CHANGE `output` `output` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;
ALTER TABLE `nagios_servicestatus` CHANGE `perfdata` `perfdata` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_statehistory` CHANGE `output` `output` TEXT CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL ;

ALTER TABLE `nagios_processevents` ADD INDEX ( `event_time` , `event_time_usec` ) ;

ALTER TABLE `nagios_hoststatus` ADD INDEX ( `current_state` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `state_type` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `last_check` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `notifications_enabled` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `problem_has_been_acknowledged` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `passive_checks_enabled` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `active_checks_enabled` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `event_handler_enabled` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `flap_detection_enabled` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `is_flapping` ) ;
ALTER TABLE `nagios_hoststatus` ADD INDEX ( `scheduled_downtime_depth` ) ;

ALTER TABLE `nagios_servicestatus` ADD INDEX ( `current_state` ) ;
ALTER TABLE `nagios_servicestatus` ADD INDEX ( `last_check` ) ;
ALTER TABLE `nagios_servicestatus` ADD INDEX ( `notifications_enabled` ) ;
ALTER TABLE `nagios_servicestatus` ADD INDEX ( `problem_has_been_acknowledged` ) ;
ALTER TABLE `nagios_servicestatus` ADD INDEX ( `passive_checks_enabled` ) ;
ALTER TABLE `nagios_servicestatus` ADD INDEX ( `active_checks_enabled` ) ;
ALTER TABLE `nagios_servicestatus` ADD INDEX ( `event_handler_enabled` ) ;
ALTER TABLE `nagios_servicestatus` ADD INDEX ( `flap_detection_enabled` ) ;
ALTER TABLE `nagios_servicestatus` ADD INDEX ( `is_flapping` ) ;
ALTER TABLE `nagios_servicestatus` ADD INDEX ( `scheduled_downtime_depth` ) ;

ALTER TABLE `nagios_statehistory` ADD INDEX ( `state_time` , `state_time_usec` ) ;

ALTER TABLE `nagios_timedeventqueue` ADD INDEX ( `event_type` ) ;
ALTER TABLE `nagios_timedeventqueue` ADD INDEX ( `scheduled_time` ) ;

ALTER TABLE `nagios_logentries` ADD INDEX ( `entry_time` ) ;
ALTER TABLE `nagios_logentries` ADD INDEX ( `entry_time_usec` ) ;

ALTER TABLE `nagios_externalcommands` ADD INDEX ( `entry_time` ) ;

-- END 1.4b7 MODS

Little
OMD - Open Monitoring Distribution

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

9

Thursday, March 5th 2009, 3:45pm

danke das werde ich gleich mal bookmarken und testen!

Ich habe viele Threads zu dem Thema DB Tuning hier im Forum gelesen aber die meisten waren ernuechternd. Viele haben den Rat erteilt statt auf InnoDB auf Heap / Memory zu setzen (klar wenn man den Arbeitsspeicher hat) aber in der Realitaet hat es dann doch kaum Performance gebracht (erinnert mich grad an Readyboost von Vista :p).

einhorn

Trainee

Posts: 94

Gender: male

Location: Oldenburg

Number of monitoring servers: 6

Nagios Version: 2.5

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: x00

Number of services: x0000

OS: Suse 9.3

Plugin Version: 1.4.1

NDO Version: 1.3.1

Perfparse Version: 0.105.6

10

Thursday, March 5th 2009, 7:28pm

Fragen zur Umgebung?

Hallo falc410!

Dein Nagios-Neustart dauert wirklich so lange? Dann gibt es einen Engpaß bei CPU, Disks (Mein "Favorit") oder Netzwerk) - und dann lohnt es sich wirklich, ein bißchen tiefer zu graben ... hier mal ein paar Fragen, die mir so spontan einfallen ...
Beim Neustart von Nagios werden (fast) als erstes historische Daten gelöscht. Wenn Du für einen Test die entsprechenden Werte in der ndomod.cfg auf "nicht löschen" stellst, hast Du einen Test, ob es das Löschen ist, was Dich bremst.
Wie ist Deine Check-Latency im Nagios (Siehe Performance-Status-Seite)?
Wie groß sind Deine Datenbank-Puffer (INNODB - eigene Index-Puffer!) eingestellt? (Reicht der Speicher?)
Wie groß ist Deine Datenbank? (Wenn sie sehr groß ist, kannst Du mit dem Anlegen der Indizes - wie unten angeben Dein Nagios für Stunden ausbremsen ... aber vielleicht hast Du die Indizes schon?)
Läuft auf der Datenbank noch mehr (außer der NDO)?
Brauchst Du die historischen Daten aus der NDO? (Ich glaube rausgelesen zu haben: ja)


Mit freundlichen Grüßen

Bernd Horn

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

11

Friday, March 6th 2009, 9:57am

RE: Fragen zur Umgebung?

Quoted from "einhorn"

Hallo falc410!

Dein Nagios-Neustart dauert wirklich so lange? Dann gibt es einen Engpaß bei CPU, Disks (Mein "Favorit") oder Netzwerk) - und dann lohnt es sich wirklich, ein bißchen tiefer zu graben ... hier mal ein paar Fragen, die mir so spontan einfallen ...

Wie gesagt, CPU sind 2x AMD Opteron Quad-Core mit je 2.3 Ghz pro Kern, RAM sind derzeit 8 GB installiert und Festplatten sind ein Hardware Raid 1 von SAS Platten allerdings mit DRBD als Partition drauf. Netzwerk faellt flach da alles auf dem gleichem Server liegt. Das ganze ist ein Sun X4140 Server. Wenn die Hardware nicht ausreicht um 10 Hosts ca. 400 Services zu monitoren dann weiss ich auch nicht.

Quoted


Beim Neustart von Nagios werden (fast) als erstes historische Daten gelöscht. Wenn Du für einen Test die entsprechenden Werte in der ndomod.cfg auf "nicht löschen" stellst, hast Du einen Test, ob es das Löschen ist, was Dich bremst.

Wie stelle ich das ein? Ich habe in der ndomod.cfg die Data Processing Options auf -1 gelassen da ich ja den Event Broker in der nagios.cfg schon beschnitten habe.

Quoted


Wie ist Deine Check-Latency im Nagios (Siehe Performance-Status-Seite)?

Das ist mir heute morgen auch schon aufgefallen, diese ist sehr sehr hoch:
Check Latency: 467.34 sec 916.08 sec 737.824 sec

Quoted


Wie groß sind Deine Datenbank-Puffer (INNODB - eigene Index-Puffer!) eingestellt? (Reicht der Speicher?)

Ich habe in der /etc/my.cnf mal das hier eingetragen: innodb_buffer_pool_size=1024M
Die Ausgaben in PHPMyAdmin zeigen nicht wirklich etwas negatives auf. Fast alles ist im gruenen Bereich.

Quoted


Wie groß ist Deine Datenbank? (Wenn sie sehr groß ist, kannst Du mit dem Anlegen der Indizes - wie unten angeben Dein Nagios für Stunden ausbremsen ... aber vielleicht hast Du die Indizes schon?)

Ich bin kein Datenbankexperte, ich weiss leider nicht wie ich die Groesse der DB herausfinde in PHPMyAdmin. Die Indexe habe ich angelegt dank dem Script von little. Ich sehe in PHPMyAdmin nur Traffic per Hour received = 17 MB. Das hoert sich jetzt nicht sehr viel an. mysqlcheck sagt auch das alles OK ist.

Quoted


Läuft auf der Datenbank noch mehr (außer der NDO)?

Nein sonst laeuft nichts mehr drauf.

Quoted


Brauchst Du die historischen Daten aus der NDO? (Ich glaube rausgelesen zu haben: ja)

Nein ich brauche nur den aktuellen Status. Habe in der ndo2db.cfg auch alle Werte auf 60 Minuten heruntergesetzt (Vorhaltezeit der Daten).

Irgendwas bremst mich hier total aus. Der Witz ist als ich gestern die Event Broker Options von -1 reduziert habe ging es fuer ein paar Stunden und dann war es sofort wieder so langsam. Ich habe keine Ahnung mehr was ich noch probieren soll. Noch staerkere Hardware auspacken? Ich kann mir nicht vorstellen das die Hardware nicht ausreicht. Und ich erkenne auch keinen Flaschenhals, das einzige was ich nicht direkt ueberpruefen kann ist die Performance von DRBD. Ich schaue hier nur per IOSTAT drauf, aber das sieht auch alles ganz normal aus. Die CPU's langweilen sich, RAM sind noch 6 GB frei (will wohl keiner nutzen) und auch ansonsten laeuft nichts auf dem Server bis auf nen Apache, DRBD, Heartbeat, MySQL und Nagios. Das wars. Wurde auf das noetigste reduziert.

einhorn

Trainee

Posts: 94

Gender: male

Location: Oldenburg

Number of monitoring servers: 6

Nagios Version: 2.5

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: x00

Number of services: x0000

OS: Suse 9.3

Plugin Version: 1.4.1

NDO Version: 1.3.1

Perfparse Version: 0.105.6

12

Friday, March 6th 2009, 10:17pm

Hallo falc410!

Wenn das Anlegen der Indizes schnell ging (wenige Minuten?) dann hast Du eine kleine DB. Ich habe mich bei so etwas schon mal länger aufgehalten (1 Stunde?).
Sehen/Abschätzen kannst Du die Tabellengrößen, Wenn Du dir den Tabellenstatus einer Tabelle anschaust.
Unter Umständen kannst Du es auch von außen sehen (wenn Die Tablespaces einigermaßen gefüllt sind): In der Regel ist es die Verzeichnisgröße des mysql-Data-Verzeichnisses für alle Datenbanken zusammen. Ich habe aber da auch schon Fehler um den FAktor 100 gesehen (Also viel "Luft" in den Dateien).


Wenn Die Datenbank "klein" ist (und das müßte sie sein, so wie Du es beschrieben hast), könnte Dich etwas von außen bremsen. Du schreibst, Du hast ein RAID 1 -- also bremst alles (Dir-Scan, Backup, ...), was Du machst, Deine Datenbank. Deine Datenbank kann Nagios dann sehr effektiv bremsen. Den Einfluß von DRBD kann ich nicht abschätzen - aber dann hast Du ein Zwillings-System -- und alle Schreibvorgänge landen auch auf Deinem Produktiv-System.

Deine Latency ist "astronomisch" (12min im Mittel).
Plottest Du Deine Latency mit? Du kannst mit Nagios Checkskripten die Latency von Nagios abfragen und als Performance-Daten abspeichern. Einen Hinweis auf ein Performance-Darstellungstool habe ich noch nicht gesehen -- aber minimal würde hier die Ausgabe in eine Textdatei reichen, um einen Eindruck zu erhalten. Das Checkskript kann man auch in einer Endlos-Schleife im Hintergrund statt von Nagios aus laufen lassen - bei Deiner Latency wäre das die zuverlässigere / ergiebigere Variante (das Ding darf man dann nur nicht vergessen ;-) ).

Was macht Deine Latency, wenn Du die DB abkoppelst?

Quoted

Wie stelle ich das ein? Ich habe in der ndomod.cfg die Data Processing Options auf -1 gelassen da ich ja den Event Broker in der nagios.cfg schon beschnitten habe.
Sorry - ich meinte die ndo2db.cfg. Dort wird das Löschen eingestellt - die Werte weiß ich leider so nicht aus dem Kopf, die stehen aber in der Installations-Anleitung drin.


Gruß

Bernd

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

13

Friday, March 20th 2009, 9:46am

Sorry, ich war jetzt 2 Wochen auf Schulung, das Problem besteht immer noch. Ich bin immer noch dran es zu loesen aber den eigentlichen Fehler bzw. Flaschenhals habe ich noch nicht gefunden.

Quoted from "einhorn"


Deine Latency ist "astronomisch" (12min im Mittel).
...
Was macht Deine Latency, wenn Du die DB abkoppelst?
...

Gruß

Bernd
Sobald ich das Broker Modul aus der nagios.cfg entferne und Nagios durchstarte ist die check_latency auf unter 1 sekunde gedrueckt. Es ist definitiv die Verbindung in Nagios - MySQL die hier bremst aber ich weiss nicht ob es am Brokermodul liegt oder an der Datenbank, einer falschen Config oder sonstwas.
Die Hardware ist sau schnell, Benchmarks auf dem DRBD zeigen dass da gut was durchgeht sind ja immerhin SAS Platten, die schnellsten die wir bekommen konnten.

Sascha

Professional

Posts: 872

Birthday: Jun 1st

Gender: male

Number of monitoring servers: 2

Nagios Version: 0.0.0

Icinga Version: 1.8.4

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: >500

Number of services: >2000

OS: Win200x, RHEL4/5/6, OES2

Plugin Version: 1.4.16

Other Addons: PNP 0.6, Brain 2.0

14

Friday, March 20th 2009, 10:47am

Moin!

Erster Kommentar zu deiner Situation: "Kann nicht sein!" ;)
Du musst irgendwas ganz grandios verfummelt haben, denn auch wenn NDO eher das Gegenteil von performant ist, ist es dann doch nicht sooo lahm. Mit DRDB kenne ich mich nicht aus, daher kann ich nur alles andere drumherum betrachten.

Poste bitte mal deine mysql config, nur um auszuschließen dass du so wirre Dinge wie querylogging oder ähnliches aus Versehen aktiviert hast.

Dann führ mal bitte folgendes durch:

- Nagios herunterfahren.
- 3 weitere Konsolen öffnen und dort folgendes starten:

- iostat -dkx 10 60 > iostat.txt
- mpstat -P ALL 10 60 > mpstat.txt

Die beiden Textfiles bitte mal hier anhängen.

- top -i

Welche Prozesse tauchen dort auf? Welche bleiben dabei lange? Poppen verschiedene Prozesse abwechselnd auf?

S

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

15

Friday, March 20th 2009, 11:18am

Hallo,

na wenigstens du hast noch Hoffnung :)
Also erstmal die my.cnf

Source code

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

#Test Entries for NDO Tuning

key_buffer = 4M
key_buffer_size = 128M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 64
table_cache = 512
query_cache_limit = 4M
query_cache_size = 32M
max_join_size = 4294967295

innodb_buffer_pool_size=1024M
join_buffer_size=128M

log_queries_not_using_indexes=yes
log-slow-queries=/var/log/mysql-slow-queries.log

# To allow mysqld to connect to a MySQL Cluster management daemon, uncomment
# these lines and adjust the connectstring as needed.
#ndbcluster
#ndb-connectstring="nodeid=4;host=localhost:1186"

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[ndbd]
# If you are running a MySQL Cluster storage daemon (ndbd) on this machine,
# adjust its connection to the management daemon here.
# Note: ndbd init script requires this to include nodeid!
connect-string="nodeid=2;host=localhost:1186"

[ndb_mgm]
# connection string for MySQL Cluster management tool
connect-string="host=localhost:1186"


Achja, MySQL ist Version 5.0.58

Bei top -i taucht nur der top Process selber auf und ab und zu mal kjournald (ich fuehre den befehl grad als root aus), der bleibt nur fuer ein paar Sekunden, dann ist wieder top alleine da.

Source code

 
1
2
3
4
5
6
7
8

Tasks: 198 total,   1 running, 197 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.7%us,  0.6%sy,  0.0%ni, 86.3%id, 12.3%wa,  0.1%hi,  0.0%si,  0.0%st
Mem:   8312268k total,  1542524k used,  6769744k free,   401792k buffers
Swap:  2040212k total,    0k used,  2040212k free,   699980k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND        
15349 root  15   0  2324 1080  804 R0  0.0   0:00.08 top            
 5124 root  10  -5 000 D0  0.0   1:14.93 kjournald


Also die Dateien sind sehr gross geworden, ich kann mit dem Output auch nichts anfangen.
Du hast gesagt ich soll Nagios ausschalten, das ist so ohne weiteres bei uns nicht moeglich. Ich habe die Befehle ausgefuehrt genau waehrend Nagios 'hochfaehrt' - das dauert bei uns ja jetzt schon so ne knappe Stunde. D.h. Nagios fuettert jetzt die DB und erst wenn das abgeschlossen ist faengt Nagios wieder an checks durchzufuehren. Ich kann jeden einzelnen Befehl in MySQL mitverfolgen, Nagios haut so pro Sekunde etwa einen Befehl raus und schreibt eben die komplette DB neu.
In den Nagios Logfiles passiert in der Zwischenzeit gar nichts, erst wenn er mit der DB fertig ist werden die alten Hoststates eingelesen und dann faengt Nagios wieder mit dem Betrieb an.

Also wenn es einen Hardware Flaschenhals gibt dann muesste er genau in diesem Stadium auftauchen und dann muesstest du es genau jetzt auch in den Dateien sehen. Ich sehe zwar das die CPU's einen hohen iowait haben, aber wie gesagt ich kann die Werte nicht interpretieren - ich kenne mich dann doch zu wenig in der Materie aus um zu erkennen ob es nun gute oder schlechte Werte sind.
falc410 has attached the following files:
  • mpstat.txt (55.62 kB - 49 times downloaded - Last download: Mar 17th 2013, 12:01am)
  • iostat.txt (18.47 kB - 61 times downloaded - Last download: Apr 20th 2013, 11:19pm)

This post has been edited 2 times, last edit by "falc410" (Mar 20th 2009, 11:33am)

Sascha

Professional

Posts: 872

Birthday: Jun 1st

Gender: male

Number of monitoring servers: 2

Nagios Version: 0.0.0

Icinga Version: 1.8.4

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: >500

Number of services: >2000

OS: Win200x, RHEL4/5/6, OES2

Plugin Version: 1.4.16

Other Addons: PNP 0.6, Brain 2.0

16

Friday, March 20th 2009, 11:50am

Das DRDB ist Schuld, da es unterirdisch schlecht performed. Allerdings kann ich dir nicht sagen woran das liegt.

Die Logs zeigen das aber ziemlich eindeutig.

Source code

 
1
2
3

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    22.80  0.00 17.10     0.00   159.60    18.67     0.01    0.56   0.08   0.14
drbd0             0.00     0.00  0.00 26.80     0.00   107.20     8.00     3.60  134.46  37.26  99.85


await + svctm ergeben die Zeit in Millisekunden, die ein einzelner Request braucht um durchgeführt zu werden.
%util zeigt an dass ein oder mehrere Prozesse auf dieses Blockdevice zugreifen und 99.85% ihrer Zeit damit verbringen nur auf die Antworten des Blockdevices zu warten.
Ein %util von ~100% bedeutet dass du in I/O Contention läufst - also das I/O System überlastet ist.

Was sagt ein

Source code

 
1

cat /sys/block/drdb0/queue/scheduler


Du könntest mal versuchen den Scheduler auf NOOP zu stellen mittels "echo noop > /sys/block/drdb0/queue/scheduler". Das könnte die Sache eventuell ein wenig beschleunigen, aber darin kann das Problem nicht begründet liegen.

Irgendwas ist mit deinem DRDB im Argen - allerdings kann ich dir da nicht wirklich weiterhelfen, da ich keine Ahnung von DRDB habe.

S

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

17

Friday, March 20th 2009, 1:01pm

Ich danke dir fuer die Erklaerung! Ich hatte schon des oefteren DRBD unter Verdacht auch wenn ich nie konkrete Beweise hatte.
Es wundert mich trotzdem, da die Festplatten ja schnell genug sind und die Rechner ueber Dual-Gigabit Cross-Over Cable angebunden sind.

Aber nun weiss ich zumindest wo ich weiter suchen kann. Der jetzige Zustand ist untragbar und auf die NDO moechte ich eigentlich nicht verzichten.

Nur mal als Vergleichswert, der iostat bei ausgeschaltetem Broker Modul:

Source code

 
1
2
3

Device:     	rrqm/s   wrqm/s   r/s   w/s	rkB/s	wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda           	0.00	38.20  1.40 30.20 	5.60   273.60	17.67 	0.07	2.19   0.41   1.31
drbd0         	0.00 	0.00  1.40 59.70 	5.60   238.80 	8.00 	5.66   92.77   1.39   8.51


Ich bin echt mal gespannt ob ich bei DRBD noch was tunen kann oder nicht.

This post has been edited 1 times, last edit by "falc410" (Mar 20th 2009, 1:23pm)

Andurin

Unregistered

18

Friday, March 20th 2009, 3:57pm

Quoted from "falc410"

Ich bin echt mal gespannt ob ich bei DRBD noch was tunen kann oder nicht.


Ich habe selbst kein DRBD laufen, aber meine gehört zu haben, dass es da ordentliche Tuningschrauben gibt.
z.B. Wie schnell/sicher soll synchronisiert werden. Könnte schon ein Unterschied machen ob jede Sekunde oder nur alle 30 Sekunden gesynced wird.

Obacht! Alles nur Annahme vom "hörensagen".

falc410

Professional

Posts: 640

Birthday: Feb 14th 1983 (30)

Gender: male

Location: Germany - Munich

Occupation: Student - Computer Science

Number of monitoring servers: 2

Hobbies: learning C# & XNA - Gamedesign, iPhone Programming

Nagios Version: 3.0.6

Distributed monitoring: Nein

Redundant monitoring: Ja

Number of hosts: 300

Number of services: 2000

OS: RHEL5

Plugin Version: 1.4.12

NagVis Version: 1.5.1

NDO Version: 1.4b7

Perfparse Version: PNP 0.6.2

Other Addons: 2 Node Cluster again with Heartbeat 2.1 & DRBD 8 / Munin 1.4

19

Tuesday, April 28th 2009, 2:56pm

Also nur um es fuer die Nachwelt festzuhalten. Es war wirklich DRBD Schuld an allem!

Vielen Dank noch einmal an Sascha ohne Ihn wuerde ich wahrscheinlich noch immer an der falschen Stelle suchen.

Alle die ein RHEL5 binaer-kompatibles OS einsetzen (CentOS oder was auch immer) kann ich nur den Tipp geben: Installiert DRBD per HAND! Benutzt nicht die Version aus YUM! Version 8.0.13/14 funktioniert einfach nicht richtig. Ich habe per Hand Version 8.3.1 installiert, hat keine 5 Minuten gedauert das make clean all und make install bzw. make install-tools einzugeben und jetzt rockt der Performance.

Ich habe vorher 2 "Tests" laufen lassen:

fuer den Durchsatz 2GB schreiben:

dd if=/dev/zero of=/drbd/2GBtestfile bs=512M count=4 oflag=direct

und mal den I/O fordern:

dd if=/dev/zero of=/drbd/testfile bs=512 count=100000 oflag=direct

Vor dem Update hatte ich einen Durchsatz von ca. 8 MB/s, nach dem update sind es ueber 60 MB/s ! Beim I/O Test hatte ich vorher eine Schreibgeschwindigkeit von ca. 3.5kb/s ! Jetzt sind es fast 4 MB/s ! Nun lueppt auch Nagios mit NDO ohne Probleme!

Similar threads