Rehash 15.05.1 - Release Notes
The primary cause of the slowdown was due to the fact that rehash did large JOIN operations on text columns in MySQL. This is bad practice in general due to performance reasons, but it causes a drastic slowdown with MySQL cluster, which prevents the query optimizer from doing what's known as a "pushdown", and allowing the query to execute on the NDB nodes. This caused article load to be O(n*m), where n was the number of articles in the database and m was the number of articles with the neverdisplay attribute set. The revised queries now load at O(1). Instead it had to do multiple pulls from the database and assemble the query data on the frontend, a process that took 4-5 seconds per problematic query. The problem was compounded that there are limited number of httpd daemons at any given moment, and any database pull that hit a problematic query (which were in index.pl and article.pl) would cause resource exhaustion.
Fortunately, our load balancer and varnish cache have a fairly high timeout waiting for httpd to come available, preventing the site from soyling itself under high load, or when we do an apache restart, which prevented SN from going down. Thank you for everyone's patience with this matter :).
~ NCommander
(Score: 5, Informative) by mrcoolbp on Tuesday June 02 2015, @10:51PM
Slashcode vs Rehash quick answer:
Basically with this major overhaul of some under-the-hood stuff (namely porting to mod_perl version 2), we've decided to differentiate our fork of slashcode with a new name -- rehash.
There's some more info in this post [soylentnews.org] (scroll down to "Introducing Rehash").
(Score:1^½, Radical)