Solid State (Oct 27 2009)


log in

Advanced search

Message boards : Technical News : Solid State (Oct 27 2009)

Author Message
Profile Matt Lebofsky
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar
Send message
Joined: 1 Mar 99
Posts: 1384
Credit: 74,079
RAC: 0
United States
Message 943207 - Posted: 27 Oct 2009, 21:59:49 UTC

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

Profile perryjay
Volunteer tester
Avatar
Send message
Joined: 20 Aug 02
Posts: 3377
Credit: 13,712,936
RAC: 12,326
United States
Message 943211 - Posted: 27 Oct 2009, 22:11:07 UTC - in response to Message 943207.

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

Profile MarkJ
Volunteer tester
Avatar
Send message
Joined: 17 Feb 08
Posts: 935
Credit: 17,768,640
RAC: 343
Australia
Message 943305 - Posted: 28 Oct 2009, 9:28:12 UTC - in response to Message 943207.
Last modified: 28 Oct 2009, 9:28:48 UTC

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

DJStarfox
Send message
Joined: 23 May 01
Posts: 1040
Credit: 527,839
RAC: 70
United States
Message 943336 - Posted: 28 Oct 2009, 14:06:40 UTC - in response to Message 943207.

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.

Message boards : Technical News : Solid State (Oct 27 2009)

Copyright © 2014 University of California