Hi Leonardo, I tried to use the my.cnf from apache-olio-php-src-0.2/webapp/php/trunk/etc/. But the mysql will not launch using the new my.cnf file. The error log says:
120708 03:33:49 mysqld_safe Starting mysqld daemon with databases from /root/jayneel/cloudsuite/webserving/web-release/mysql-5.5.20-linux2.6-x86_64/data 120708 3:33:49 [Note] Plugin 'FEDERATED' is disabled. 120708 3:33:49 [Warning] option 'innodb-autoextend-increment': unsigned value 104857600 adjusted to 1000 120708 3:33:49 InnoDB: The InnoDB memory heap is disabled 120708 3:33:49 InnoDB: Mutexes and rw_locks use GCC atomic builtins 120708 3:33:49 InnoDB: Compressed tables use zlib 1.2.3 120708 3:33:49 InnoDB: Using Linux native AIO 120708 3:33:49 InnoDB: Initializing buffer pool, size = 2.0G 120708 3:33:49 InnoDB: Completed initialization of buffer pool 120708 3:33:49 InnoDB: highest supported file format is Barracuda. InnoDB: No valid checkpoint found. InnoDB: If this error appears when you are creating an InnoDB database, InnoDB: the problem may be that during an earlier attempt you managed InnoDB: to create the InnoDB data files, but log file creation failed. InnoDB: If that is the case, please refer to InnoDB: http://dev.mysql.com/doc/refman/5.5/en/error-creating-innodb.html 120708 3:33:49 [ERROR] Plugin 'InnoDB' init function returned error. 120708 3:33:49 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 120708 3:33:49 [ERROR] Unknown/unsupported storage engine: innodb 120708 3:33:49 [ERROR] Aborting 120708 3:33:49 [Note] /root/jayneel/cloudsuite/webserving/web-release/mysql-5.5.20-linux2.6-x86_64/bin/mysqld: Shutdown complete 120708 03:33:49 mysqld_safe mysqld from pid file /root/jayneel/cloudsuite/webserving/web-release/mysql-5.5.20-linux2.6-x86_64/data/sc-h03.cs.wisc.edu.pid ended I am not sure what is the trouble with InnoDB settings. Did you make any changes to the my.cnf file? Thanks, Jayneel > 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 >
