<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Tue, Dec 3, 2019 at 7:37 PM Roberto Ostinelli <<a href="mailto:ostinelli@gmail.com">ostinelli@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="ltr">This function nothing is but a single postgres query, a “select * from users where id = ‘123’”, properly indexed.</div><div dir="ltr"><br></div></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If it transfers 2 gigabyte of data, then this single postgres query is going to take some time.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If someone is doing updates which require a full table lock on the users table, this query is going to take some time.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div dir="ltr"></div><div dir="ltr">The only thing I can see is a latency towards the db (infra-aws regions unfortunately). It really is that at a certain moment, randomly (sometimes after 5 minutes, other times after 2 days) this happens and there’s no recovery whatsoever. </div><div dir="ltr"><br></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Other tricks:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* If your initial intuitive drill down into the system bears no fruit, start caring about facts.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* Measure the maximal latency over the equery call you've made for a 10-15 second period. Plot it.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* We are interested in microstutters in the pacing. If they are present, it is likely there is some problem which then suddenly tips the system over. If not, then it is more likely that it is something we don't know.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* The database might be fast, but there is still latency to the first byte, and there is the transfer time to the last byte. If a query is 50ms, say, then you are only going to run 20 of those per connection.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* Pipeline the queries. A query which waits for an answer affects every sibling query as well.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Down the line:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* Postgres can log slow queries. Turn that on.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">* Postgres can log whenever it holds a lock for more than a certain time window. Turn that on.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Narrow down where the problem can occur by having systems provide facts to you. Don't go for "what is wrong?" Go for "What would I like to know?". This helps observability (In the Control Theory / Charity Majors sense).</div><br></div></div></div>