Web Lamp Server

[bronco]

I imagine that the bottleneck is

Why guessing? It's Linux so you can simply have a look what's really happening

Please post the output of the following in a code block after your blog has been accessed a little bit and you feel it slows down:

Code: Select all

vmstat -w

[martigs]

When I get home I'll try it with the computer.

With the htop command of dietpi I realized when I accessed the blog, the cpu is triggered 100%, the 512mb memory is more or less in half.

[martigs]

# vmstat -w
procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu--------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 37536 43496 234000 0 0 0 1 67 7 1 0 98 0 0



Attached a htop capture plus the vmstat when I access the page to show you the results is an rpi b + of 512mb.

[MichaIng]

Hmm, so RAM is not the problem, but a stuck/overloaded webserver thread. Interestingly only one of the 4 default threads is in use, so it doesn't seem to be due to too much simultaneous access?

Does it only occur, if you use MariaDB as underlying database? Maybe Apache somehow stuck at accessing the database. Please check:
"/var/log/apache2/error.log" and/or "journalctl -u apache2"
"/var/log/mysql/error.log" or "/var/log/mysql.err" and/or "journalctl -t mysqld"
if you see any errors there.

Does "dietpi-services restart" fix the issue or does it reappear shortly?
Might be due to wrong configured apache module and/or mariadb then.

[martigs]

journalctl -u apache2

-- Logs begin at Thu 2018-03-08 08:35:07 CET, end at Wed 2018-03-14 19:35:57 CET. --
mar 08 08:35:43 Rpi-Srv systemd[1]: Starting The Apache HTTP Server...
mar 08 08:35:44 Rpi-Srv apachectl[945]: [Thu Mar 08 08:35:44.784857 2018] [core:error] [pid 956]
(EAI 2)Name or service not known: AH00547: Could not resolve host name *:80="" -- ignoring!
mar 08 08:35:45 Rpi-Srv systemd[1]: Started The Apache HTTP Server.

journalctl -t mysqld

-- Logs begin at Thu 2018-03-08 08:35:07 CET, end at Wed 2018-03-14 19:39:20 CET. --
mar 08 08:35:49 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:49 3069299920 [Note] /usr/sbin/mys
qld (mysqld 10.1.23-MariaDB-9+deb9u1) starting as process 1184 ...
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: Using
mutexes to ref count buffer pool pages
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: The I
nnoDB memory heap is disabled
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: Mutex
es and rw_locks use GCC atomic builtins
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: GCC b
uiltin __atomic_thread_fence() is used for memory barrier
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: Compr
essed tables use zlib 1.2.8
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: Using
Linux native AIO
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: Using
generic crc32 instructions
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: Initi
alizing buffer pool, size = 128.0M
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: Compl
eted initialization of buffer pool
mar 08 08:35:50 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:50 3069299920 [Note] InnoDB: Highe
st supported file format is Barracuda.
mar 08 08:35:51 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:51 3069299920 [Note] InnoDB: 128 r
ollback segment(s) are active.
mar 08 08:35:51 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:51 3069299920 [Note] InnoDB: Waiti
ng for purge to start
mar 08 08:35:51 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:51 3069299920 [Note] InnoDB: Perc
ona XtraDB (http://www.percona.com) 5.6.35-80.0 started; log sequence number 10239770
mar 08 08:35:51 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:51 2529162048 [Note] InnoDB: Dumpi
ng buffer pool(s) not yet started
mar 08 08:35:51 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:51 3069299920 [Note] Plugin 'FEEDB
ACK' is disabled.
mar 08 08:35:51 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:51 3069299920 [Note] Server socket
created on IP: '127.0.0.1'.
mar 08 08:35:52 Rpi-Srv mysqld[1185]: 2018-03-08 8:35:52 3069299920 [Note] /usr/sbin/mys
qld: ready for connections.
mar 08 08:35:52 Rpi-Srv mysqld[1185]: Version: '10.1.23-MariaDB-9+deb9u1' socket: '/var/
run/mysqld/mysqld.sock' port: 3306 Raspbian 9.0

these are the logs of the states, all the applications of the system are installed with dietpi-software and practically configured in the same way, can not be due to lack of CPU?

[MichaIng]

I just checked via Nextcloud on my RPi2:
- Requests are separated on several apache instances quickly, resulting on all 4 cores being used equally, by times quite up to 100% but just for short time, until request/page load done.
- On idle CPU usage is nearly constant 0% on all 4 cores.
- So absolutely no problem for my nearly only home and family Nextcloud instance with 2 mobile and 2 desktop clients syncing regularly.

But yeah if you constantly have concurrent requests to handle, then the RPi will be obviously on it's limits, slowing done fast. Maybe nginx or lighttpd (php-pfm) can handle things better, but as for my research, they do only perform noticeable better on 25+ concurrent requests. But this is an amount, where anyway a RPi is not suitable any more for sure.

[martigs]

The page does not have many visits when I execute it, I am the one who enters to do the test and the ago when I see that iftop does not have more connections than mine.

The raspberry pi b + is a cpu of a 700mhz core diepi through overlooking to get to 900mhz but always in a single core because the pi has no more I think it is not software if not hardware.

At first I wanted to configure it with lighttpd and mariadb but I have the blog with https through letsncrypt and I only managed to boot it with apache.

[MichaIng]

The latest DietPi supports letsencrypt/certbot in combination with Lighttpd as well, including HSTS and automatic certificate renewal. But I guess Lighttpd does not have it's strength in less CPU usage, but in less memory usage, which might not help you.

But it might be still worth trying, as I cannot believe that simply running the webserver leads to significant CPU usage, even on RPi1 with 1 core. So do full sd card backup and fresh DietPi image and then fresh Apache or Lighttpd setup (as said, should not make significant difference) with CertBot + Wordpress and see if the issue still occurs.

dietpi-backup and Apache uninstallation + Lighttpd installation as alternative with bid less effort, but a clean image has it's benefits as well .

[martigs]

Finally I saw that it was not a matter of memory as we discussed if not of cpu with an orange pi one that I got in a store nearby I configure everything and the blog is luxurious. Thank you very much for the help.