I think so, I used the same file and after 72 hours I had not been able to
load the database. I used the one pointed to Cansu and it took just some
hours.

On Saturday, July 7, 2012, Jayneel Gandhi wrote:

> Hi Leonardo,
>
> The mysql conf file was copied from
>
> cp mysql-5.5.20-linux2.6-x86_64/**support-files/my-medium.cnf /etc/my.cnf
>
> as per the instructions on the webpage. In that conf file innodb plugin is
> not enabled at all. Am I using the wrong conf file?
>
>
> Thanks,
> Jayneel
>
> On 07/07/2012 10:26 PM, Leonardo Piga wrote:
>
>> Cansu answered this question some time ago. It did solve my problem.
>> Maybe you are having the same issue.
>>
>>
>> Dear Leonardo,
>> Most probably, this is because of the disk write latency that the
>> insertion operations are exposed to. You can verify it by checking the
>> vmstat output, the 'wa' field.
>> If the wait time is high, please compare your MySQL configuration
>> parameters with the ones in my.cnf, under
>> apache-olio-php-src-0.2/**webapp/php/trunk/etc/.
>> In particular, make sure that the buffer pool and log buffer are large
>> (need tuning depending on the aggregate memory size).
>> Moreover, make sure that innodb_doublewrite and
>> innodb_flush_log_at_trx_commit parameters are  set to 0 and 2
>> respectively as in my.cnf, so that the database is exposed to the disk
>> latency at the minimum.
>>
>>
>>
>> Leonardo
>>
>>
>> On Sat, Jul 7, 2012 at 10:22 PM, Jayneel Gandhi<[email protected]>
>>  wrote:
>>
>>> Hi,
>>>
>>> The script dbloader.sh takes a lot of time (script has been running for
>>> hours) to load to database even with a load factor of 100. Can anyone
>>> comment on what should be used as the load factor in case we do want to
>>> simulate for larger number of concurrent users (maybe ~100s or ~1000s)?
>>> Also, what kind of runtime should I expect to load the database in that
>>> case.
>>>
>>> Thanks,
>>> Jayneel
>>>
>>
>

-- 
Leonardo

Reply via email to