Jump to content

mariadb standard logfile location fills up zram /var/log


Franky66

Recommended Posts

I went into a problem after setting up mariadb / nextcloud installation nativ on my armbian installation odroid n2. per default the logfiles for mariadb (bin files) are logged to /var/log which is only 50 mb because of in memory usage (zram). So after some usage the whole installation stucked because of "out of disk usage" in /var/log.

 

So I stopped nginx, php and mariadb and created a new logfile location in /var/log.mariadb and changed the necessary entries in /etc/mysql/my.conf and started the necessary services again. For now the usage is propper again in /var/log.

 

Maybe this is useful for other people or other had another solution for this.

 

Regards

Link to comment
Share on other sites

I think we will have to modify Armbian Server a bit so that it works correctly with SSD and HDD drives.
In my case I have a server with public Ip, primary disk of 120GB SSD and another secondary of 320GB type HDD.
On the server I installed ispConfig, wordpress, nextcloud and icecast2
I think it would be best to move all the Logs on the HDD disk so as not to damage the SSD disk over time ... and of course remove the /var/log and /tmp partitions.
What do you think?

Link to comment
Share on other sites

@maxlinux2000 the actual setup is working fine for me. Igor give the right hint for tuning the log destination. I will check this. If I understand right, armbian is configured for delay write the log files to disk (specially sd cards) so that the sd cards are longer usable during less writing.

 

Removing the partitions is not useful as a lot of linux services need this standard locations :-)

 

@Igor Thankx for your hint. I was not sure were armbian is configured for the ram log disk. So will have a look and tune.

Link to comment
Share on other sites

2 minutes ago, Franky66 said:

armbian is configured for delay write the log files to disk (specially sd cards) so that the sd cards are longer usable during less writing.

 
Writing small chunks is what shorten SD card live dramatically. Optimisations are done on different levels but most important are that we use compressed memory device for storing logs (write to SD once per day) and root file-system commit configuration "is about the frequency with which the file-system driver itself forces a FULL sync of ALL dirty data/journal/metadata/whatever to the physical media."

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines