1.查看cpu个数
cat /proc/cpuinfo |grep "physical id" |sort | uniq |wc -l
2
2.查看cpu逻辑个数
cat /proc/cpuinfo |grep "processor"|wc -l
16
3.查看cpu核数
cat /proc/cpuinfo |grep "cores"|uniq
4
4.查看CPU的主频
select ENGINE,ROUND(SUM(data_length + index_length)/1024/1024,1) as total
from information_schema.tables
where table_schema not in ("information_schema","performance_schema") group by ENGINE;
需要大于数据和索引大小的和。
9.commit 方式 ,建议设置成2.
innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit = 0,Innodb 中的Log Thread 每隔1 秒钟会将log buffer中的数据写入到文件,同时还会通知文件系统进行文件同步的flush 操作,保证数据确实已经写入到磁盘上面的物理文件。但是,每次事务的结束(commit 或者是rollback)并不会触发Log Thread 将log buffer 中的数据写入文件。所以,当设置为0 的时候,当MySQL Crash 和OS Crash 或者主机断电之后,最极端的情况是丢失1 秒时间的数据变更。
innodb_flush_log_at_trx_commit = 1,这也是Innodb 的默认设置。我们每次事务的结束都会触发Log Thread 将log buffer 中的数据写入文件并通知文件系统同步文件。这个设置是最安全的设置,能够保证不论是MySQL Crash 还是OS Crash 或者是主机断电都不会丢失任何已经提交的数据。
innodb_flush_log_at_trx_commit = 2,当我们设置为2 的时候,Log Thread 会在我们每次事务结束的时候将数据写入事务日志,但是这里的写入仅仅是调用了文件系统的文件写入操作。而我们的文件系统都是有缓存机制的,所以Log Thread 的这个写入并不能保证内容真的已经写入到物理磁盘上面完成持久化的动作。文件系统什么时候会将缓存中的这个数据同步到物理磁盘文件Log Thread 就完全不知道了。所以,当设置为2 的时候,MySQL Crash 并不会造成数据的丢失,但是OS Crash 或者是主机断电后可能丢失的数据量就完全控制在文件系统上了。各种文件系统对于自己缓存的刷新机制各不一样,大家可以自行参阅相关的手册。
根据上面三种参数值的说明,0的时候,如果mysql crash可能会丢失数据,可靠性不高。我们着重测试1和2两种情况。
10.读写线程数默认为4.
innodb_read_io_threads
innodb_write_io_threads
netstat -anpl | grep mbd