[General] Any linux gurus?

Thu Dec 12 13:37:31 CST 2013

Here's something else to think about.  Is the program writing out the data
in sequential chuncks, or is it writing to random parts of the file?

With buffered writes the best speed up you can get with a raid 0 array is
if one disk is writing something while the other disk is going to the place
where the next thing is going to be written.  If you're dealing with a
bunch of random writes, then ponying up for a few SSDs or refactoring the
code might be worth it.

Assuming that your raid controller isn't the bottleneck.  Some motherboard
based raid controllers use the CPU to do the work, and can cause everything
to slow down.  (Side note.  Does anyone know if DMA works with those kind
of controllers?)

On Thu, Dec 12, 2013 at 11:26 AM, Stephan Henning <shenning at gmail.com>wrote:

> The program will write out a file of variable size, it's based on the
> problem being run. Currently, it writes out approximately 1.5TB for the
> benchmark problem, most of that contained in a single file, much too large
> for a ramdisk. Unfortunately, the problems have grown so large that they
> can't be run in ram any more. This is a GPU accelerated program so this
> file gets modified very heavily during the process of a run.
>
> Current testing is being done on a Raid0 of 5c Crucial 960G SSDs. This has
> proven to be significantly faster than the old array, but I am trying to
> determine exactly how hard the disks are being hammered so I can try and
> optimize the hardware configuration.
>
> The program is compiled from source, but I'm not involved in that process,
> I'd much rather try and piggyback something and monitor the process than
> try and go in and have something added to source.
>
> I'll add parted and gparted to my list of things to read up on, thanks.
>
>
> On Thu, Dec 12, 2013 at 12:29 AM, David <ainut at knology.net> wrote:
>
>>  Excellent approach.
>>
>>
>>
>> Arthur wrote:
>>
>> How big are the files that you're dealing with?
>> If they're small you can just make a ramdisk and try running everything
>> in there.
>> It's not a final solution, but between that and strace you should be able
>> to see if that's really the issue or not.
>>
>>  Are you compiling from source?  If you are, then there are a bunch of
>> debugging tools you can use as well as doing things like timing individual
>> commands, and seeing how many times each line of code is run.
>>
>>
>> On Wed, Dec 11, 2013 at 10:48 PM, Stephan Henning <shenning at gmail.com>wrote:
>>
>>> This is a RedHat6 Enterprise install.
>>>
>>>  I don't think htop has the data I need, but I'll check. I'm not
>>> familiar with ntop and I didn't consider using trace for this, I'll check
>>> that as well.
>>>
>>>  The goal is to record read/write rates and block sizes. I'm pretty
>>> sure I am bottlenecking against the drive array, I'm hoping I can get some
>>> definitive answers from this.
>>>
>>>
>>> On Wed, Dec 11, 2013 at 6:01 PM, David <ainut at knology.net> wrote:
>>>
>>>>  ntop might do the trick, but not available in Fedora.
>>>>
>>>>
>>>>
>>>> David wrote:
>>>>
>>>> Can 'htop' show open files?
>>>>
>>>> For intensive live net data, look at WireShark for linux.
>>>>
>>>>
>>>> David wrote:
>>>>
>>>> If that's what you're looking for, there are several (free) programs
>>>> you could run from the command line in a separate window/screen while your
>>>> program is running that give you all you're asking about.  Sort of an
>>>> equivalent to Winblows "System Explorer."  What flavor or Linux are you
>>>> using?
>>>>
>>>> David M.
>>>>
>>>>
>>>> Devin Boyer wrote:
>>>>
>>>> Try something like "strace -T myapp" or "strace -T -c myapp"; they'll
>>>> show the system calls being made and the amount of time spent in each.
>>>>  It's slightly different information than iostat, but it may be useful in
>>>> figuring out what and where your program is performing io access.
>>>>
>>>>
>>>> On Wed, Dec 11, 2013 at 3:37 PM, Stephan Henning <shenning at gmail.com>wrote:
>>>>
>>>>>   No, iostat will normally just dump to the terminal window, but I'd
>>>>> like to pipe it's output to a file so I can parse it later.
>>>>>
>>>>>  My end goal here is to be able to generate a log of iostat output
>>>>> while I run this program, I'm trying to determine exactly how hard this
>>>>> program is hitting my harddrive and at what points during it's run does it
>>>>> access the drive the most frequently.
>>>>>
>>>>>  I've done something similar in bash before, but it is rather clunky.
>>>>>
>>>>>  I'll take a look at exec and see if I can use it.
>>>>>
>>>>>
>>>>> On Wed, Dec 11, 2013 at 4:46 PM, David <ainut at knology.net> wrote:
>>>>>
>>>>>>  Do you need to do anything with the results or just need them
>>>>>> displayed?
>>>>>> If you need to manipulate the results, consider using Perl,
>>>>>> or if C or C++,
>>>>>> in your 'exec' call, pipe the output to a file, then just read that
>>>>>> file into your program.
>>>>>> Ain't UNIX great?
>>>>>>
>>>>>>
>>>>>> David M.
>>>>>>
>>>>>>
>>>>>> Stephan Henning wrote:
>>>>>>
>>>>>>  I'd like to take some metrics with iostat while I have a specific
>>>>>> program running, is there a way to wrap iostat around another program (it
>>>>>> is called from the command line) so that iostat ends when the program
>>>>>> finishes running?
>>>>>>
>>>>>>  I know I can do it with a bash script, but I'm hoping for a more
>>>>>> elegant solution.
>>>>>>
>>>>>>
>>>>>>  _______________________________________________
>>>>>> General mailing listGeneral at lists.makerslocal.orghttp://lists.makerslocal.org/mailman/listinfo/general
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> General mailing list
>>>>>> General at lists.makerslocal.org
>>>>>> http://lists.makerslocal.org/mailman/listinfo/general
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> General mailing list
>>>>> General at lists.makerslocal.org
>>>>> http://lists.makerslocal.org/mailman/listinfo/general
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> General mailing listGeneral at lists.makerslocal.orghttp://lists.makerslocal.org/mailman/listinfo/general
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> General mailing listGeneral at lists.makerslocal.orghttp://lists.makerslocal.org/mailman/listinfo/general
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> General mailing listGeneral at lists.makerslocal.orghttp://lists.makerslocal.org/mailman/listinfo/general
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> General mailing list
>>>> General at lists.makerslocal.org
>>>> http://lists.makerslocal.org/mailman/listinfo/general
>>>>
>>>
>>>
>>> _______________________________________________
>>> General mailing list
>>> General at lists.makerslocal.org
>>> http://lists.makerslocal.org/mailman/listinfo/general
>>>
>>
>>
>>
>>  --
>> Sincerely,
>> Arthur Moore
>> (256) 277-1001
>>
>>
>> _______________________________________________
>> General mailing listGeneral at lists.makerslocal.orghttp://lists.makerslocal.org/mailman/listinfo/general
>>
>>
>>
>> _______________________________________________
>> General mailing list
>> General at lists.makerslocal.org
>> http://lists.makerslocal.org/mailman/listinfo/general
>>
>
>
> _______________________________________________
> General mailing list
> General at lists.makerslocal.org
> http://lists.makerslocal.org/mailman/listinfo/general
>

-- 
Sincerely,
Arthur Moore
(256) 277-1001
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.makerslocal.org/pipermail/general/attachments/20131212/dfc6ca1c/attachment-0001.html>