在繁重的mysql服务器上内存使用率高的时候CPU使用率是否太低?

我使用的是Ubuntu的服务器12.04 x64。 服务器通过apache web服务器接收到很多对mysql的请求(它是轻量级的接口)。 从MySQL统计看,从上午8点到晚上9点,大约有250个查询/秒。 在晚上服务器实际上不使用。 RAM主要由mysql使用(根据mysqloptimizer的最大MySQL内存使用量是25GB)。 最高确认 – mysql使用大约77%的内存。

数据库大小约20GB。 一张桌子在最重的火下有大约1到2百万条logging(主要是几张桌子上的ID字段加上一些smallint计数器)。

我附加了图像ilustrating我感兴趣的部分(第二个内存图像显示服务器重新启动后的内存行为)。 在这里输入图像说明

在看慕宁时,我想出了几个问题:

  1. 为什么在内存useage apps内存几乎永远不会下降? 在服务器没有stream量的情况下,是否应该降低,例如在晚上?

  2. 难道不是更好的调整它使caching更多的内存空间?

  3. 为什么在RAM满了的时候CPU使用率很低?

  4. 不活跃的记忆水平也在上升,这让我担心一点。

这些问题是因为偶尔在短时间内stream量大幅上升,而在那些时候服务器没有回应很多请求。 但是在那个时候,内存/ CPU甚至是磁盘延迟都不会上升很多,或许还有一点点。 这些stream量的增加是不可避免的,但我不知道是否用stringerreplace服务器会做,或者只能放更多的RAM(因为CPU使用率是最小的)?

如果这个问题是无法回答的 – 对不起。

编辑:#MySQL数据库服务器configuration文件。 ##可以复制到#/“/etc/mysql/my.cnf”中设置全局选项#〜“〜/ .my.cnf”来设置用户特定的选项。 ##可以使用程序支持的所有长选项。 #使用–help运行程序,获取可用选项的列表,并使用#–print-defaults来查看它实际上可以理解和使用的选项。 ##解释请参阅#http://dev.mysql.com/doc/mysql/en/server-system-variables.html

 # This will be passed to all mysql clients # It has been reported that passwords should be enclosed with ticks/quotes # escpecially if they contain "#" chars... # Remember to edit /etc/mysql/debian.cnf when changing the socket location. [client] port = 3306 socket = /var/run/mysqld/mysqld.sock # Here is entries for some specific programs # The following values assume you have at least 32M ram # This was formally known as [safe_mysqld]. Both versions are currently parsed. [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] # # * Basic Settings # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. #bind-address = 127.0.0.1 # # * Fine Tuning # key_buffer = 64M max_allowed_packet = 16M thread_stack = 192K thread_cache_size = 64 # This replaces the startup script and checks MyISAM tables if needed # the first time they are touched myisam-recover = BACKUP max_connections = 400 table_cache = 6000 #thread_concurrency = 10 # # * Query Cache Configuration # query_cache_limit = 1M query_cache_size = 32M # # * Logging and Replication # # Both location gets rotated by the cronjob. # Be aware that this log type is a performance killer. # As of 5.1 you can enable the log at runtime! #general_log_file = /var/log/mysql/mysql.log #general_log = 1 # # Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf. # # Here you can see queries with especially long duration slow_query_log = 0 slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 20 #log-queries-not-using-indexes # # The following can be used as easy to replay backup logs or for replication. # note: if you are setting up a replication slave, see README.Debian about # other settings you may need to change. #server-id = 1 #log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M #binlog_do_db = include_database_name #binlog_ignore_db = include_database_name # # * InnoDB # # InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. # Read the manual for more InnoDB related options. There are many! # # * Security Features # # Read the manual, too, if you want chroot! # chroot = /var/lib/mysql/ # # For generating SSL certificates I recommend the OpenSSL GUI "tinyca". # # ssl-ca=/etc/mysql/cacert.pem # ssl-cert=/etc/mysql/server-cert.pem # ssl-key=/etc/mysql/server-key.pem innodb_file_per_table innodb_flush_method=O_DIRECT innodb_log_file_size = 512M innodb_buffer_pool_size = 24G bulk_insert_buffer_size = 256M innodb_open_files = 6000 innodb_flush_log_at_trx_commit = 2 innodb_lock_wait_timeout = 50 innodb_file_io_threads = 4 thread_cache_size = 64 thread_concurrency = 12 query_cache_size = 64M query_cache_limit = 2M max_sp_recursion_depth = 50 thread_stack = 384K tmp_table_size = 64M max_heap_table_size = 64M key_buffer_size = 32M event_scheduler = ON lower_case_table_names = 1 [mysqldump] quick quote-names max_allowed_packet = 16M [mysql] #no-auto-rehash # faster start of mysql but no tab completition [isamchk] key_buffer = 16M # # * IMPORTANT: Additional settings that can override those from this file! # The files must end with '.cnf', otherwise they'll be ignored. # !includedir /etc/mysql/conf.d/ 

数据库(99%)caching他们所能做的一切。 caching是好的。 它使东西更快。 你想让你的数据库服务器吃掉所有的内存,除非必须释放。

它不会caching的东西,除非你问(如在查询中)。 也许有工具可以使MySQL预caching数据,但我不知道。 较新的数据库产品开始获得大量的内存function,您可以在其中select某些数据,以便始终保存在内存中。

CPU使用率与RAM使用率无关。 你的查询可能是非常轻量级的,就像只有每次碰到索引的细粒度SELECTS一样。 换句话说,数据库将为您驻留在RAM中的caching数据提供服务,因此将不会有太多的CPU工作要做(如调度I / O以从磁盘检索和处理数据)。

对我来说,这看起来像一个非常健康和快速执行的数据库。 真的没有任何问题。 如果你有空闲的内存,那么这只是意味着数据库不需要caching更多的数据,因为它永远不会被请求。

编辑:你已经限制了InnoDB池到24GB,这是非常好的,因为你的数据库是20GB。 如果数据库增加,请注意增加缓冲池大小。 您还提到,您担心可用内存的减less – 如果数据库之外的其他进程正在使用它,这应该只是一个问题。 数据库服务器不会超出您所限制的范围。