On 11/20/2013 12:29 AM, lst_hoe02 AT kwsoft DOT de wrote:
> Zitat von Charles Douglass <chas.douglass AT gmail DOT com>:
>
>> On 11/13/2013 09:01 AM, Phil Stracchino wrote:
>>> On 11/13/13 10:59, Charles Douglass wrote:
>>>> Thanks for the reply.
>>>>
>>>> I know nothing about MySQL optimization.  I downloaded the
>>>> "mysqltuner.pl" script and I will run it after the next full backup to
>>>> see if it has any recommendations.
>>> The mysqltuner script is a pretty decent basic tool.  The thing you need
>>> to keep in mind regarding the "mysql-large", "mysql-huge" sample
>>> configurations that are STILL widely distributed in MySQL packages (and
>>> still widely used by the unsuspecting) is that most of those sample
>>> configurations were originally written back when a "large" server was
>>> one that might have as much as a whole 32MB of RAM.  These days, that is
>>> less than the compiled-in default size of some individual MySQL
>>> *buffers*.  So the unwary install the "suggested" configurations, and
>>> can't understand why MySQL is performing like a geriatric tortoise.
>>>
>>>
>> I ran mysqltuner before the backup and increased a couple of buffer
>> sizes as well as taking this suggestion:
>>
>> innodb_flush_log_at_trx_commit=0
>>
>>
>> Then I ran a full backup and see this:
>>
>> 18-Nov 12:45 maple-sd JobId 46: Sending spooled attrs to the  
>> Director. Despooling 153,470,245 bytes ...
>> 18-Nov 21:41 maple-dir JobId 46: Bacula maple-dir 5.2.6 (21Feb12):
>>   Build OS:               x86_64-pc-linux-gnu ubuntu 13.04
>>
>> So spooling/despooling took just about 9 hours.
>>
> Even for MySQL on a not too fast machine this is ridiculus slow. We  
> despool around 1.2GB attributes within around 2 minutes to our  
> Postgres server. Something is still wrong with your setup. Have you  
> checked with tools like iotop,top,vmstat what the server is actually  
> doing during the 9 hours.
>
> Regards
>
> Andreas
>
iostat during the attrs despooling shows:
                                           
  334 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [jbd2/sda1-8]
24997 be/4 mysql       0.00 B/s   64.98 K/s  0.00 %  0.12 % mysqld

Doing some research this appears to be a problem between MySQL and ext4
with file system journaling (jbd2/sda1-8).

Thanks, everyone, for helping me get this far. 

My next step will be to create an ext3 partition and move all my MySQL
Dbs there.

Chas Douglass



------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users