在大部分情下，应该使 InnoDB 缓冲池和可用内存保持一致，但是，在少数情况下，很大的缓冲池（比如 50GB）会导致长时间的延迟。比如，大型的缓冲池在检查点或插入缓存合并操作的时候会变慢，并且并发也会因为锁定而减少。如果遇到了这些问题，就应该减少缓冲池的大小。

可以改变 innodb_max_dirty_pages_pct 的值，让 InnoDB 改变保留在缓冲池中被修改的页面的数量。如果允许保留更多修改的页面，InnoDB 就需要更长的时间来关闭，因为它会在关闭之前把修改的页面写入数据文件。可以强制它快速关闭，但是它在重新启动时候就会要做更多的恢复工作，所以这实际上不能加快从关闭到启动的周期。如果预先知道需要关闭，就可以把这个变量设置为较小的值，并等待它为冲刷线程以清理缓冲池，然后在修改的页面数量变小的时候关闭 InnoDB。可以通过观察状态变量 innodb_buffer_pool_pages_dirty 或使用 innotop 监视 SHOW INNODB STATUS 的值来检测修改过的页面的数量。

In most cases, you should make the InnoDB buffer pool as large as your available memory allows. However, in rare cirumstances, very large buffer pools (say, 50GB) can cause long stalls. For example, a large buffer pool may become slow during checkpoints or insert buffering merge operations, and concurrency can drop as a result of locking. If you experience these problems, you may have to reduce the buffer pool size.

You can change the innodb_max_dirty_pages_pct variable to instruct InnoDB to keep more or fewer dirty(modified) pages in the buffer pool. If you allow a lot of dirty pages, InnoDB can take a long time to shut down, because it writes the dirty pages to the data files upon shutdown. You can force it to shut down quickly, but then it just has to do more recovery when it restarts, so you can’t actually speed up the shutdown and restart cycle time. If you know in advance when you need to shut down, you can set the variable to a lower value, wait for the flush thread to clean up the buffer pool, and then shut down once the number of dirty pages becomes small. You can monitor the number of dirty pages by watching the Innodb_buffer_pool_pages_dirty server status variable or using innotop to monitor SHOW INNODB STATUS.

前面一段时间，估计是我把不太友善，编译时，libevent libaray 一再的出错，明明已经安装，但编译时还是报找不着，用 --with-libevent-dir 参数指定照样出错，搜了下，找到这个 【configure fails to pick up a custom prefix for libevent】，详细内容，请移步这里

对于自己，对于别人，我想，我总是不够坦然的。很多的情，很多的话，总是因为自己那该死的拘窘，羞怯，卑怯的心理，不感诉诸于口。

也不知道为什么要将这段话放在这里，也许，一切都没有那么多的缘由的..