<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:media="http://search.yahoo.com/mrss/"><channel><title><![CDATA[debug - Matthias Lee - Musings on Software and Performance Engineering]]></title><description><![CDATA[Matthias Lee is a Software Performance Engineer, Technical Lead and Computer Science PhD. Currently a Principal Performance Engineer at Appian.]]></description><link>https://matthiaslee.com/</link><image><url>https://matthiaslee.com/favicon.png</url><title>debug - Matthias Lee - Musings on Software and Performance Engineering</title><link>https://matthiaslee.com/</link></image><generator>Ghost 2.14</generator><lastBuildDate>Fri, 21 Nov 2025 21:24:19 GMT</lastBuildDate><atom:link href="https://matthiaslee.com/tag/debug/rss/" rel="self" type="application/rss+xml"/><ttl>60</ttl><item><title><![CDATA[Debugging mysql crash on a low-memory VPS]]></title><description><![CDATA[<p>Recently I had a run-in with a seemingly random, occasional crash of mysql on a system with only 512MB of memory. My suspicion was that sometimes mysql runs some cleanup tasks or something along those lines, causing the memory usage to spike and ultimately cause a crash. So I wrote</p>]]></description><link>https://matthiaslee.com/debugging-mysql-crash-on-a-low-memory-vps/</link><guid isPermaLink="false">5a0a60d882e47c00018dabe0</guid><category><![CDATA[mysql]]></category><category><![CDATA[low memory]]></category><category><![CDATA[crash]]></category><category><![CDATA[debug]]></category><dc:creator><![CDATA[Matthias A. Lee]]></dc:creator><pubDate>Sat, 28 Mar 2015 02:16:00 GMT</pubDate><content:encoded><![CDATA[<p>Recently I had a run-in with a seemingly random, occasional crash of mysql on a system with only 512MB of memory. My suspicion was that sometimes mysql runs some cleanup tasks or something along those lines, causing the memory usage to spike and ultimately cause a crash. So I wrote this quick and dirty script to log 48 hours of memory:</p>
<pre><code>#!/usr/bin/env python
import os
import datetime
import psutil
 
# This script will dump the memory state and write it to mem.log
# if more than 2880 entries are in the log file, it will start removing 
# old ones in order to keep the log size down.
#
# To use this script first install psutil: sudo pip install psutil
# then run: crontab -e
# add this line to the bottom(adjust the path to where the script is): 
# * * * * * cd /home/madmaze/trash; /usr/bin/python /home/madmaze/trash/memoryLogger.py
#
# This will write add a new entry to mem.log every minute and keep 48hrs of records
 
def getUsage():
    m=psutil.virtual_memory()
    s=psutil.swap_memory()
    memkeys=[&quot;total&quot;, &quot;available&quot;, &quot;percent&quot;, &quot;used&quot;, &quot;free&quot;, &quot;active&quot;, &quot;inactive&quot;, &quot;buffers&quot;, &quot;cached&quot;]
    swapkeys=[&quot;total&quot;, &quot;used&quot;, &quot;free&quot;, &quot;perc&quot;,&quot;sin&quot;,&quot;sout&quot;]
    info={}
    # MEM
    for n,k in enumerate(m):
        if memkeys[n] not in [&quot;percent&quot;,&quot;active&quot;,&quot;inactive&quot;]:
            info[&quot;mem_&quot;+memkeys[n]]=str(k/1024/1024)+&quot; MB&quot;
 
    # SWAP
    for n,k in enumerate(s):
        if n &lt; 3:
            info[&quot;swap_&quot;+memkeys[n]]=str(k/1024/1024)+&quot; MB&quot;
    
    return info
 
 
logfile=&quot;mem.log&quot;
f_in=open(logfile,&quot;r&quot;)
lines=f_in.readlines()
f_in.close()
 
totalLen=len(lines)
maxlen=2*24*60	# 2days * 24hr * 60m
 
if totalLen &gt; maxlen+100:
    # Crop file to length
    f_out=open(logfile,&quot;w&quot;)
    for n,l in enumerate(lines):
        if (totalLen-n)&lt;maxlen:
            f_out.write(l)
else:
    # just append
    f_out=open(logfile,&quot;a&quot;)
 
# Actually append the next line of data
f_out.write(str(datetime.datetime.now())+&quot; &quot;+str(getUsage())+&quot;\n&quot;)
f_out.close()
</code></pre>
<p>Github Gist: <a href="https://gist.github.com/madmaze/560cbcf0392aab824820">https://gist.github.com/madmaze/560cbcf0392aab824820</a></p>
<p>Judging by the recorded memory usage pattern, it seems that at 3AM EST a series of database intensive cron jobs kicked off at the same time causing mysql's memory foot print to grow until it crashed. Long story short, I spaced the cron jobs out such that each has plenty of time to complete before the next one begins.</p>
]]></content:encoded></item></channel></rss>