PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Welche Wiki-Software für kleinen Server?



shor
06.08.08, 22:53
Hallo!

Ich habe hier einen kleinen Server :) mit 500Mhz und 256MB RAM stehen auf dem ich gerne für mich selbst ein Wiki laufen lassen möchte.
Im Moment läuft da ein Mediawiki drauf, das anfangs grottenschlecht lief (ca. 3s für die Anfrage einer Seite) und inzwischen nach umstellen auf eine MyISAM MySQL-Datenbank und installieren eine php caching Systems (APC) einigermaßen flott (ca. 1 bis 1,5s pro Anfrage) läuft.
Wenn ich ein bisschen hektisch "rumklicke" geht die CPU-Auslastung auf 100% - vermute also mal dass das der Flaschenhals ist - RAM sind meistens noch 100MB frei.

Jetzt habe ich mich gefragt, ob es nicht andere Wikis gibt, die etwas weniger Performance fressen. Wäre nett, wenn jemand seine Erfahrungen dazu schildern könnte bevor ich stupide anfange alle durchzuprobieren... :ugly:

Grüße und Danke,
shor

marce
07.08.08, 06:32
auf auf einem solchen System läuft Mediawiki völlig problemlos und auch flott - erst recht, wenn Du der einzige Benutzer bist.

Ich tippe mal eher auf eine nicht-optimal konfiguriert MySQL-DB - auch bei 256MB Ram kann man das eine oder ander MB davon in z.B. Query-Caches investieren...

bla!zilla
07.08.08, 06:53
Also ich habe auf weitaus schwächeren Systemen performance PHP/MySQL Applikationen laufen gehabt. Ich denke auch, und stimme Marce zu, dass deine Config wohl nicht ganz optimal ist. Schau dir mal die Werte mittels top oder vmstat an. Achte dabei auch hohe IOwait Werte.

shor
08.08.08, 21:45
Hallo!

Das meine MySQL DB nicht optimal konfiguriert ist dürfte zutreffen! ;) Das liegt zum einen daran, dass ich mich zwar mit SQL ganz gut auskenne aber leider nicht damit wie man eine Datenbank optimiert.
Und zum anderen daran, dass ich entweder zu doof zum suchen bin (das einzige was ich auftreiben konnte war das: http://dev.mysql.com/doc/refman/5.1/de/option-files.html - und das hilft mir nicht weiter) oder man für diese Informationen wohl löhnen muss.

Ich habe unter /usr/local/share/mysql verschiedene Konfigurationsdateien für kleine, große, mitllere und riesige ;) Systeme gefunden. Leider trifft keine der Fälle für meine System 100%ig zu und ohne die Infos, an welchen Schrauben ich genau drehen muss, sitze ich auf dem Trockenen.

Ein Auszug aus meiner my.cnf:



key_buffer = 50M
max_allowed_packet = 1M
table_cache = 2M
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 512K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M


Für Tips wie ich was einstellen soll und was das genau bewirkt wäre ich sehr dankbar! :D

Grüße,
shor

Jigsore
08.08.08, 23:38
Wenn Du MySQL weiterhin auf dem Server nutzen willst/musst, schau Dir mal http://www.day32.com/MySQL/ -> Tuning-Primer Script an. Das Script gibt hilfreiche Tips zum optimieren.

Ansonsten: http://wiki.splitbrain.org/wiki:dokuwiki ;)

marce
09.08.08, 08:16
... die Optionsdateien, die Du gefunden hast (kleine - riesige) geben aber einen Anhaltspunkt, woran man drehen kann.

Die Notwendigen Infos sind übrigens problemlos online abrufbar: http://dev.mysql.com/doc/refman/5.1/de/server-system-variables.html

shor
09.08.08, 08:46
Ahja! :) Irgendwie hat es bei mir bei dem Begriff "Server-Systemvariablen" nicht klick gemacht ;) Hab wohl nach den falschen Begriffen gesucht.

Na dann acker ich mich da mal durch das Skript und das Referenzhandbuch und poste dann wieder was ich verändert habe.

THX!

shor
09.08.08, 21:44
Also, ich habe in dem MySQL Referenzhandbuch nachgelesen und das tuning-primer Skript ausgeführt.

Das Skript hat mir nicht wirklich weitergeholfen - es meint nur meine Key Buffer size wäre zu hoch und sonst ist alles (angeblich) im grünen Bereich.

Im Referenzhandbuch hab ich noch was über querie caches gelesen und das mal ausprobiert. Gefühlt bringt das ein bisschen was - aber ich würde sagen dass ist immer noch zu langsam.

Habe folgendes der my.cnf hinzugefügt:

# enable query cache
set-variable = query_cache_size=1000000

Habe auch mal ein bisschen vmstat laufen lassen während ich eine Weile in dem Wiki "rumgeklickt" habe:


# vmstat -w 1
procs memory page disk traps cpu
r b w avm fre flt re pi po fr sr wd0 int sys cs us sy id
0 0 0 56484 147624 25 0 0 0 0 0 1 230 70 15 1 0 99
0 0 0 56492 147616 26 0 0 0 0 0 0 232 98 17 0 1 99
0 0 0 56492 147616 7 0 0 0 0 0 0 235 32 17 0 0 100
2 0 0 59436 144672 1768 0 0 0 0 0 0 259 2967 93 54 8 38
0 0 0 56488 147620 591 0 0 0 0 0 0 257 1794 73 30 2 68
0 0 0 56492 147616 479 0 0 0 0 0 0 238 1017 43 17 2 81
0 0 0 56496 147612 1883 0 0 0 0 0 0 280 3799 123 69 4 27
0 0 0 56496 147612 7 0 0 0 0 0 0 234 34 18 0 1 99
0 0 0 56496 147612 7 0 0 0 0 0 0 232 28 13 0 1 99
1 0 0 59208 144868 711 0 0 0 0 0 2 235 1923 66 41 2 57
1 0 0 59532 144544 88 0 0 0 0 0 0 233 127 13 99 1 0
1 0 0 59548 144528 19 0 0 0 0 0 0 232 843 21 100 0 0
0 0 0 56512 147548 1886 0 0 0 0 0 0 282 4056 112 72 9 19
0 0 0 56512 147548 23 0 0 0 0 0 0 256 272 29 1 1 98
0 0 0 56512 147548 7 0 0 0 0 0 0 232 28 13 0 0 100
1 0 0 59792 143560 851 0 0 0 0 0 12 240 9113 56 33 6 61
1 0 0 60864 142488 293 0 0 0 0 0 0 232 1853 45 98 2 0
1 0 0 60864 142488 7 0 0 0 0 0 0 233 134 17 100 0 0
2 0 0 60420 142932 1397 0 0 0 0 0 0 280 2936 79 81 7 12
0 0 0 57128 145972 539 0 0 0 0 0 22 293 1919 106 29 3 67
0 0 0 57128 145972 11 0 0 0 0 0 0 233 40 15 0 0 100
0 0 0 57128 145972 7 0 0 0 0 0 0 232 33 15 1 0 99
0 0 0 57128 145972 7 0 0 0 0 0 0 244 28 15 0 0 100
1 0 0 60528 142668 893 0 0 0 0 0 8 244 1657 62 47 4 49
1 0 0 60504 142240 1071 0 0 0 0 0 20 247 7377 129 84 5 10
1 0 0 60504 142240 11 0 0 0 0 0 0 232 140 17 100 0 0
1 0 0 58020 144724 169 0 0 0 0 0 0 278 1662 37 86 2 12
0 0 0 57564 145180 1742 0 0 0 0 0 0 263 3411 110 66 5 28
0 0 0 57564 145180 7 0 0 0 0 0 0 232 28 13 0 0 100
0 0 0 57560 145184 474 0 0 0 0 0 0 234 959 40 19 1 81
0 0 0 57572 145172 1871 0 0 0 0 0 0 280 3799 128 69 5 26
0 0 0 57572 145172 7 0 0 0 0 0 0 232 34 15 0 0 100
1 0 0 60352 142392 712 0 0 0 0 0 0 234 423 16 61 2 36
1 0 0 60352 142392 7 0 0 0 0 0 0 233 142 15 100 0 0
1 0 0 62364 139804 546 0 0 0 0 0 14 239 8439 46 97 3 0
1 0 0 62444 139724 130 0 0 0 0 0 0 232 5677 37 97 3 0
2 0 0 58212 143956 639 0 0 0 0 0 0 300 2408 62 88 2 10
0 0 0 58040 144128 1301 0 0 0 0 0 0 262 2585 89 50 2 48
0 0 0 58040 144128 478 0 0 0 0 0 0 234 1014 37 18 1 81
0 0 0 58016 144136 1901 0 0 0 0 0 0 295 3969 133 66 11 23
0 0 0 58016 144136 11 0 0 0 0 0 0 239 40 15 1 0 99
0 0 0 58016 144136 7 0 0 0 0 0 0 232 35 15 1 0 99


Hat jemand noch einen Tip woran ich noch drehen könnte?
Kann ich nicht einfach die ganze DB in den Speicher laden? :D

Grüße,
shor

bla!zilla
10.08.08, 10:47
Lass mal das Skript (http://serversupportforum.de/forum/sql/14308-tuning-primer-script.html) über deinen Server laufen.

shor
10.08.08, 18:50
Wie gesagt, dass Skript hat nicht viel geholfen, es meint es wäre alles gut.
Ich habe es jetzt nochmal laufen lassen, der Server lief allerdings nicht ganz 48h, was aber egal ist, da der Output ähnlich dem ersten run ist den ich gemacht habe.

Hier das Ergebnis


SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 1 sec.
You have 0 out of 2678 that take longer than 1 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is enabled
The expire_logs_days is not set.
The mysqld will retain the entire binary log until RESET MASTER or PURGE MASTER LOGS commands are run manually
Setting expire_logs_days will allow you to remove old binary logs automatically
See http://dev.mysql.com/doc/refman/5.0/en/purge-master-logs.html

WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 1
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 1
Historic max_used_connections = 2
The number of used connections is 2% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

ls: unknown option -- H
usage: ls [-1AaCcdFfghikLlmnopqRrSsTtux] [file ...]
MEMORY USAGE
./tuning-primer.sh: line 1238: [: too many arguments
Max Memory Ever Allocated : 46 M
Configured Max Per-thread Buffers : 183 M
Configured Max Global Buffers : 42 M
Configured Max Memory Limit : 226 M
./tuning-primer.sh: line 351: [: physical_memoryHR: integer expression expected
./tuning-primer.sh: line 357: [: physical_memoryHR: integer expression expected
./tuning-primer.sh: line 363: [: physical_memoryHR: integer expression expected
./tuning-primer.sh: line 370: export: `2=physical_memoryHR': not a valid identifier
Physical Memory : bytes
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 169 K
Current key_buffer_size = 32 M
Key cache miss rate is 1 : 20
Key buffer fill ratio = 0.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 976 K
Current query_cache_used = 175 K
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 17.95 %
Current query_cache_min_res_unit = 4 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 512 K
Current read_rnd_buffer_size = 508 K
No sort operations have been performed
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 0 queries where a join could not use an index properly
Your joins seem to be using indexes properly

ls: unknown option -- H
usage: ls [-1AaCcdFfghikLlmnopqRrSsTtux] [file ...]
OPEN FILES LIMIT
Current open_files_limit = 3580 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 1735 tables
You have a total of 52 tables
You have 52 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 107 temp tables, 7% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 508 K
Current table scan ratio = 1 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 0 : 2858
Your table locking seems to be fine

shor
10.08.08, 19:52
Ich habe gerade mal ein Festplatten-Benchmark-Tool namens Bonnie laufen lassen:


# bonnie
File './Bonnie.13789', size: 104857600
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 19619 94.0 23313 18.5 6981 9.3 11987 67.2 23439 25.2 150.1 1.6

Denke dass sollte eigentlich ok sein, oder? Nicht dass irgendwas anderes das System ausbremst und ich an der falschen Ecke bastle...

marce
10.08.08, 20:13
läuft der Server eigentlich 24/7 durch oder startest Du den immer nach Bedarf?

shor
10.08.08, 20:28
Läuft 24/7. Ich starte nur den mysqld öfters neu, wenn ich an der my.cnf geschraubt habe...

Wene
10.08.08, 21:19
Für den kleinen Bedarf kann ich wie Jigsore auch zu Dokuwiki raten. Hat bei schwächerer Hardware den Vorteil dass es ganz ohne DB auskommt. Die Seiten werden in Textdateien gespeichert.

marce
11.08.08, 06:03
Läuft 24/7. Ich starte nur den mysqld öfters neu, wenn ich an der my.cnf geschraubt habe...
dabei beachten: Auch mit Caches sind die ersten Messergebnisse immer Mau - ein Cache muss ja erst mal gefüllt werden...

cane
11.08.08, 21:58
Tolle Matrix vieler gängiger Wikis: http://wikimatrix.org

mfg
cane

shor
16.08.08, 22:44
Hmm. Also DokuWiki sagt mir vom Look&Feel her nicht so arg zu ;) Läuft aber definitv schneller.
Die Matrix-Seite ist aber ein guter Tip - das ist ja inzwischen der reinste Urwald, den es da an Wiki-Software gibt! ;)

Ein kleines Quentchen konnte ich noch aus dem Server rausholen indem ich die binary logs deaktiviert habe.
Anregung dazu kam aus diesem thread: http://www.linuxforen.de/forums/showthread.php?t=254359

shor
16.08.08, 23:07
Was mir gerade beim längeren betrachten von mytop auffällt:

Die Anzahl bei "Queries: 457.0 qps" steigt die ganze Zeit über (ca. 1 Query pro Sekunde). Ist das normal? Stellt da mytop irgendwelche Anfragen an die DB? Ode läuft da was seltsames im Hintergrund?



MySQL on localhost (5.0.51a) up 0+00:13:36 [02:04:26]
Queries: 457.0 qps: 1 Slow: 0.0 Se/In/Up/De(%): 16/00/00/00
qps now: 0 Slow qps: 0.0 Threads: 1 ( 1/ 0) 00/00/00/00
Key Efficiency: 87.9% Bps in/out: 3.6/537.0 Now in/out: 8.3/ 1.3k

Wene
17.08.08, 18:27
Hmm. Also DokuWiki sagt mir vom Look&Feel her nicht so arg zu ;)

Dafür gibt es doch Templates (http://www.dokuwiki.org/template).

shor
18.08.08, 20:59
Jau, die hab ich schon gesehen ;) Das ist zwar jetzt "gemein" :ugly: aber mir gefällt mediawiki irgendwie besser...
Die Performance ist jetzt halt so an der es-nervt-leicht-aber-ist-benutzbar Grenze. Von daher werde ich erstmal dabei bleiben.
Mit meinem Optimierungslatein bin ich zZ am Ende - falls ich nochmal irgendwo ein paar ms rausquetschen kann, gebe ich Bescheid an welchem Rädchen ich gedreht habe.

Nochmal ein abschließendes DANKE an alle Helfer! :)

Gruß,
shor