As many of you already know, Tuesday is the regular outage day where we dry clean the mysql database and pack it down tight. We're recovering from it now. Today I also did some testing of the newly employed solid state RAID 1 on mork (the master mysql server). It seemed fine, so this device now holds the mysql/innodb logical logs, thus resulting in far less competing writes with the data RAID 10 (where the logs used to be kept). Will this help much? I dunno. A non-zero amount at least.

I'm still assembling the new data pipeline. Got a few files in the queue now for multibeam analysis, but I can't seem to get a new astropulse splitter to compile. I need to recompile so that it reads the software radar blanking bit instead of the hardware one, but I'm hitting some library/include issues. Sigh. One of those problem you know you'll get working eventually but right now the path isn't exactly clear, and everything will be annoying until you finally get a successful "make."

- Matt

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

Hang in there Matt, you'll get it going. I mentioned in your last thread I've finished three of the "new" WUs with your software blanking. They worked just fine and two of them had already validated. I think I've finished a couple more but the replica hasn't caught up yet so I don't know how they did. I'm sure they are fine too.

Looking forward to the newly blanked APs, bet they are just as problem free as the MBs.

---

PROUD MEMBER OF Team Starfire World BOINC

As many of you already know, Tuesday is the regular outage day where we dry clean the mysql database and pack it down tight. We're recovering from it now. Today I also did some testing of the newly employed solid state RAID 1 on mork (the master mysql server). It seemed fine, so this device now holds the mysql/innodb logical logs, thus resulting in far less competing writes with the data RAID 10 (where the logs used to be kept). Will this help much? I dunno. A non-zero amount at least.

Good to hear. Will be interesting to see how they work out. Would also be interested to see how they go size-wise as they aren't that big.

I'm still assembling the new data pipeline. Got a few files in the queue now for multibeam analysis, but I can't seem to get a new astropulse splitter to compile. I need to recompile so that it reads the software radar blanking bit instead of the hardware one, but I'm hitting some library/include issues. Sigh. One of those problem you know you'll get working eventually but right now the path isn't exactly clear, and everything will be annoying until you finally get a successful "make."

Sound like my normal work day, trying to work out why programs don't work any more and fix without breaking something else. I'm sure you'll crack it soon, if you haven't already.

Cheers

---

BOINC blog

Matt,

In the past, I had a specific server scenario where the log files were larger than the actual database. There was a lot of data moving around, and the transaction logs were a bottleneck, competing with disk I/O for data. I agree that the separate logical drive for transaction logs should improve overall write performance. Plus, it's always cool to have cutting-edge technology (solid state drives) a server. :)

One other (real quick) thing to check is swapfile usage on your database server. You don't want the database engine using any swap. If you can find and remove any unnecessary swapping, then I/O performance will be a little better.

Cheers to the new software-blanked radio data. That's a significant accomplishment for SETI when you stop and think about it. Can't wait to crunch some of it.