<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le lun. 30 janv. 2017 à 17:49, Francesco Di Mizio <<a href="mailto:francescodimizio@gmail.com">francescodimizio@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">Digging this up again. Havent moved to a physical server yet. I will first be splitting the bbot server and postgres on different hosts.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">What I've noticed the CPU spiking is always (and I rea) due to queries like:</div><div class="gmail_msg">SELECT logchunks.first_line, logchunks.last_line, logchunks.content, logchunks.compressed FROM logchunks WHERE logchunks.logid = 56343 ORDER BY logchunks.first_line<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">If I am correct that call can only come from <a href="https://github.com/buildbot/buildbot/blob/cfe60e31206748bcf01232eb13c0d6177cd04d5d/master/buildbot/db/logs.py#L252" class="gmail_msg" target="_blank">CompressLog</a> . They do take a very long time (even 1 minute). While running all the system is stuck. I wonder if I should use some custom postgres config, I am simply running the official postgres 9.5 container. </div></div></blockquote><div>Hi Francesco,</div><div>If your logs are not anormally large, like you said already this should not take one minute.</div><div><br></div><div>That said, I have released in 0.9.3 an optimization that removes that particular request so that the compression happens on a stream of smaller requests.</div><div><br></div><div>You might consider an upgrade in order to see if the situation improves.</div><div><br></div><div>Pierre</div></div></div>