{"id":540,"date":"2008-03-26T19:54:44","date_gmt":"2008-03-27T03:54:44","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/good-fate-housekeeping\/"},"modified":"2020-07-25T23:10:41","modified_gmt":"2020-07-26T06:10:41","slug":"good-fate-housekeeping","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/good-fate-housekeeping\/","title":{"rendered":"Good FATE Housekeeping"},"content":{"rendered":"

The front page of FATE<\/a> may not look all that different, save for some new tests every few days. But I assure you I am doing a lot of work on the backend to improve the whole thing. I finally deployed the optimizations outlined in this post<\/a>. That put the brakes on the unrestrained growth of the database (2.5 GB in as many months). I also thought of another –ahem–<\/em> groundbreaking optimization: If the client-side test script compresses the stdout or stderr for a build record and the compressed size is larger than 64K, there’s really no reason to send it over and store it in the database– the database won’t be able to decompress the data block anyway after it is truncated to 64K. This is the case for every single icc build. Intel’s C compiler insists on operating in a pedantic mode that I can’t seem to disable, despite the options documentation. Fortunately, I have been logging total stderr line count for for several weeks now (though I haven’t made it available via the web interface yet).<\/p>\n

So what to do about this enormous database? At first, I suspected that all those specious icc stderr blobs had a significant impact. But no: that’s only occupying 13 MB. Still, that useless data is now gone.<\/p>\n

The real space pigs are the cumulative stderr\/stdout blobs logged prior to my space-saving epiphany:<\/p>\n

\r\nmysql> SELECT \r\n  SUM(LENGTH(stdout)), \r\n  SUM(LENGTH(stderr)) \r\n  FROM test_result;\r\n+---------------------+---------------------+\r\n| SUM(LENGTH(stdout)) | SUM(LENGTH(stderr)) |\r\n+---------------------+---------------------+\r\n|          1337031227 |          1096300800 |\r\n+---------------------+---------------------+\r\n<\/pre>\n
Whoa. So that’s where all the space went. That’s right: ~1.3 GB and ~1.1 GB, respectively. Getting rid of the stderr blobs is pretty straightforward. I don’t care about stderr if the test was successful:<\/p>\n
\r\nmysql> UPDATE test_result\r\n  SET stderr=NULL\r\n  WHERE test_passed=1;\r\n<\/pre>\n
The stdout blobs are a bit trickier. If the test failed, the stdout is always a keeper, just like stderr. If the test succeeded, I still want the stdout data if the corresponding test spec listed the expected stdout as being NULL– that means the stdout is supposed to be retained for logging purpose. This is presently used for tracking the assorted binaries’ filesizes over time and I don’t want to drop that data. So it seems I need data from another table in order to make this query work. Sounds like a job for an JOIN operation, which didn’t seem to be possible per the raw syntax spec. I’m glad I turned out to be wrong as indicated by this blog post<\/a>. So I cloned a small test table and went to work prototyping it backwards and forwards, lest I lose 3 months of precious filesize data.<\/p>\n
\r\nmysql> UPDATE test_result result \r\n  INNER JOIN test_spec spec\r\n  ON result.test_spec=spec.id\r\n  SET result.stdout=NULL \r\n  WHERE result.test_passed=1\r\n  AND spec.expected_stdout IS NOT NULL;\r\n<\/pre>\n
Things are a bit more manageable now and I’m happy to report that I have a fighting chance of implementing a regular, automated backup schedule for FATE:<\/p>\n
\r\n+---------------------+---------------------+\r\n| SUM(LENGTH(stdout)) | SUM(LENGTH(stderr)) |\r\n+---------------------+---------------------+\r\n|             2046425 |             4292739 |\r\n+---------------------+---------------------+\r\n<\/pre>\n
I hope you have enjoyed yet another installment of The New Adventures Of The Amazingly Inept DBA<\/em>.<\/p>\n","protected":false},"excerpt":{"rendered":"
The front page of FATE may not look all that different, save for some new tests every few days. But I assure you I am doing a lot of work on the backend to improve the whole thing. I finally deployed the optimizations outlined in this post. That put the brakes on the unrestrained growth […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[101],"tags":[],"class_list":["post-540","post","type-post","status-publish","format-standard","hentry","category-fate-server"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/posts\/540","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/comments?post=540"}],"version-history":[{"count":2,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/posts\/540\/revisions"}],"predecessor-version":[{"id":4614,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/posts\/540\/revisions\/4614"}],"wp:attachment":[{"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/media?parent=540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/categories?post=540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/multimedia.cx\/eggs\/wp-json\/wp\/v2\/tags?post=540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}