3 ms·
At the point you see the load drop on the following graph, we switched from MySQL to Redis: http://db.lloogg.com/load.dir/load-1month.png http://db.lloogg.com/
by antirez 17y ago
At the point you see the load drop on the following graph, we switched from MySQL to Redis:
http://db.lloogg.com/load.dir/load-1month.png http://db.lloogg.com/load.dir/load-1month.png
Alternative DBs are not good for everything, but SQL databases are not good for everything as well...
- sounddust 17y agoI'm sorry, but this graph says nothing. Load average is meaningless; for example, one process using 100% CPU at all times would show a load of 1.0, and one process that repeatedly spawns threads but uses little cpu can push the load average very high. What's the difference in maximum number of pages served per second using ab? Or average CPU usage? Or average disk throughput? I'm not saying I disagree with your conclusion, but this doesn't prove it.
- antirez 17y agogot your point actually, you can see all the data here: http://db.lloogg.com http://db.lloogg.com, there are many stats about load, disk I/O, and so on.
- easp 17y agoThat sheds some light on things. One thing that doesn't make sense to me is that your disk writes are completely flat now, no real variation through the day.
- sounddust 17y agoThat's much more interesting data, but it clearly shows that the reason Redis was performing better is because it's caching a ton of data in memory, whereas MySQL was constantly hitting the disk for access. This seems to be a misconfiguration of either your kernel settings or MySQL settings. If Redis effectively cached your entire dataset in RAM, then MySQL could have done so as well (or the kernel could have). I'm guessing that you configured MySQL in a way that caused the kernel to fight with the database over memory usage.
- trezor 17y agoMySQL can hardly be called representative for good relational databases. That MySQL is underfeatured and performs like shit for any non-trivial query is hardly news.