Danke Marneus..
> welche Hardware Dir zur Verfügung steht,
webtropia, der billigste vserver 256ram
"Virtual Starter"
https://www.webtropia.com/home/virtual-server.html
> was drauf läuft/laufen soll mit welchen Zugriffszahlen (keine Eigeninterpretation á la "gut besucht", sondern Fakten!)
spaeter soll mal rechenintensive PHP scripte drauf laufen, aber
im augenblick laeuft nur plesk und eine domain auf der ein paar bilder sind.
Re: Traffic:
Im Plesk ist alles auf 0 bytes.. und heisst es zu webalizer traffic stats:
This is the placeholder for Web statistics. If you see this page, that means that statistics for your server was not gathered yet, or bandwidth was not used.
Hat Webtropia das Plesk schlecht eingerichtet? Ich hab KEINE traffic oder Webstatistics-auswertung, aber die Logfiles sind da.
Ich hab mal schnell die Statistiken zu fuss erstellt:
cd /var/www/vhosts/MYDOMAIN.TLD/httpdocs/temp
webalizer -o . /var/www/vhosts/MYDOMAIN.TLD/statistics/logs/access_log
heraus kam:
500 hits am tag -- von 50 sites -- traffic 6mB am tag
> wie Deine Apache2 server-tuning.conf aussieht,
hab ich keine
find / -iname "server-tuning.conf"
find: WARNING: Hard link count is wrong for /proc/vz/vzaquota: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.
:~#
> was das tuning-primerscript.sh (suche hier im Forum danach) ausgibt,
super, hab ich gefunden!
https://serversupportforum.de/threads/mysql-performance-tuning-mit-tuning-primer-sh-script.13785/
wget -Nc
http://www.day32.com/MySQL/tuning-primer.sh
./tuning-primer.sh
mysqld is alive
-- MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -
MySQL Version 5.0.32-Debian_7etch6-log i486
Uptime = 22 days 23 hrs 55 min 25 sec
Avg. qps = 0
Total Questions = 90891
Threads Connected = 1
Server has been running for over 48hrs.
It should be safe to follow these recommendations
To find out more information on how each of these
runtime variables effects performance visit:
MySQL :: MySQL 5.0 Reference Manual :: 5.1.3 System Variables
Visit
MySQL :: MySQL Enterprise Advisors
for info about MySQL's Enterprise Monitoring and Advisory Service
SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10 sec.
You have 0 out of 90912 that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.
BINARY UPDATE LOG
The binary update log is enabled
WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 5
Current threads_per_sec = 0
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 = 6
The number of used connections is 6% 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
MEMORY USAGE
Max Memory Ever Allocated : 57 M
Configured Max Per-thread Buffers : 265 M
Configured Max Global Buffers : 42 M
Configured Max Memory Limit : 307 M
Physical Memory : 5.68 G
Max memory limit seem to be within acceptable norms
KEY BUFFER
Current MyISAM index space = 96 K
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 7
Key buffer fill ratio = 0 %
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 = 16 M
Current query_cache_used = 3 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 19.53 %
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 = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine
JOINS
Current join_buffer_size = 132.00 K
You have had 45 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.
Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.
OPEN FILES LIMIT
Current open_files_limit = 1024 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 = 64 tables
You have a total of 152 tables
You have 64 open tables.
Current table_cache hit rate is 10%, while 100% of your table cache is in use
You should probably increase your table_cache
TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 8660 temp tables, 0% 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 = 128 K
Current table scan ratio = 16 : 1
read_buffer_size seems to be fine
TABLE LOCKING
Current Lock Wait ratio = 0 : 91092
Your table locking seems to be fine
> was cat /proc/user_beancounters zu tage fördert
cat /proc/user_beancounters
Code:
Version: 2.5
uid resource held maxheld barrier limit failcnt
37086: kmemsize 5782343 5798956 15728640 25728640 318
lockedpages 0 0 4096 4096 0
privvmpages 66644 66681 128451 131072 0
shmpages 5799 5799 131072 131072 0
dummy 0 0 0 0 0
numproc 61 61 350 350 0
physpages 24740 24740 0 2147483647 0
vmguarpages 0 0 65536 2147483647 0
oomguarpages 25445 25445 65536 2147483647 0
numtcpsock 20 20 400 400 0
numflock 10 10 200 220 0
numpty 1 1 64 64 0
numsiginfo 0 1 512 512 0
tcpsndbuf 185588 185588 1020920525 1074653184 0
tcprcvbuf 327680 327680 1020920525 1074653184 0
othersockbuf 26388 26388 1020920525 1074653184 0
dgramrcvbuf 0 0 262144 262144 0
numothersock 21 21 400 400 0
dcachesize 0 0 4192304 4317184 0
numfile 1970 1978 4096 4096 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 14 14 128 128 0
Hier ist noch der output von top:
Code:
top - 18:41:02 up 23 days, 2:25, 1 user, load average: 0.00, 0.02, 0.02
Tasks: 46 total, 1 running, 45 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0% us, 0.1% sy, 0.0% ni, 99.8% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 5958028k total, 5865188k used, 92840k free, 236776k buffers
Swap: 7164980k total, 8352k used, 7156628k free, 2747372k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 16 0 1868 656 560 S 0 0.0 0:50.67 init
1388 root 15 0 1556 572 456 S 0 0.0 0:10.49 syslogd
1405 root 16 0 1672 592 496 S 0 0.0 0:00.42 inetd
1428 root 16 0 4856 1116 788 S 0 0.0 0:04.05 sshd
1551 root 16 0 2132 888 708 S 0 0.0 0:05.82 cron
12032 root 18 0 2596 1328 1080 S 0 0.0 0:00.00 mysqld_safe
12092 mysql 16 0 131m 27m 5696 S 0 0.5 5:19.48 mysqld
12093 root 15 0 1480 504 440 S 0 0.0 0:00.00 logger
28357 root 15 0 41096 6740 4172 S 0 0.1 0:00.56 httpsd
17612 bind 16 0 36696 3192 1968 S 0 0.1 0:17.10 named
7204 root 15 0 4176 856 660 S 0 0.0 0:00.00 couriertcpd
7208 root 16 0 3100 872 688 S 0 0.0 0:00.00 courierlogger
7236 root 20 0 4176 844 648 S 0 0.0 0:00.00 couriertcpd
7241 root 19 0 2972 720 552 S 0 0.0 0:00.00 courierlogger
7261 root 15 0 4188 860 660 S 0 0.0 0:00.08 couriertcpd
7264 root 16 0 3096 868 688 S 0 0.0 0:00.01 courierlogger
7282 root 18 0 4176 844 648 S 0 0.0 0:00.00 couriertcpd
Ich merke schon... MySQL braucht den halben Speicher...
Plesk braucht MySQL, nicht wahr? Wir brauchen es nicht.
Ich wette du stimmst mir zu, wenn ich sage:
Besser alles nochmal neu, mit einem nackten Debian...
Aber warum sollte Apache abschmieren.. es gibt doch swapspace!!
Danke im Voraus..
APACHE LIEF NICHT MEHR
