这是一个创建于 3248 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们现在有台日志服务器 总容量 2T 内存 2G 4 核服务器 表关系比较简单 就是俩表 一个表记录 session 触发的时间和条件 另一个表统计当前 session 包含了多少条内容
现在用分表 （ postgresql 分表功能感觉不是很好）在单表数据量到 300w 以后发现插入性能下降的特别明显 可能是索引太多 插入速度也就达到刚开始的 1/10 插入日志的时候磁盘 io 较高 请问有没有什么好的优化方案
或者可用 nosql 或者别的数据库处理 谢谢！ 小弟数据库这方面积累比较薄弱 麻烦大神指教 谢谢
 | 1 yidinghe 2016-11-20 10:56:48 +08:00 如果楼主觉得索引太多，可以尝试减少索引。如果确实是这个原因的话，恐怕换成 nosql 性能也高不起来。日志这东西也就一个日期时间索引就可以了吧。 |
 | 2 ryd994 2016-11-20 10:58:21 +08:00 via Android 既然是日志服务器，能不能陈旧数据分离转移？ 另外索引设置是否合理？ 有没有钱上 SSD ？至少热数据要在 SSD 里 内存 2G 也许不是很够，检查一下是不是所有索引能放得下？ |
 | 3 Banio OP @ryd994 我们第一个表是 11 个索引 对应我们网页端 的 11 个筛选条件 也不知道是不是合理。。。 300w 条的时候 每个索引就将近 100m 了 索引是都放在内存中读取吗。。。那看来是不够了 其实我们这日志系统要求比较简单 插入 删除 查询 不涉及更新什么的 |
| 4 ryd994 2016-11-20 11:27:48 +08:00 via Android @Banio 一般要求索引在内存里，否则性能会很差 11 个筛选条件也许有重合可以精简索引，这个不是我专业 |
 | 5 jimzhong 2016-11-20 13:08:14 +08:00 增加内存试试， 2G 偏小了 |
 | 6 owt5008137 2016-11-20 13:15:16 +08:00 via Android perf top 看下？ 2GB 内存确实有点小。看看交换区是不是占用过大呗？ linux 的交换区性能屎一样 |
 | 7 Banio OP |
| 8 Banio OP @owt5008137 每次都发现内容占用满了 但是 swap 分区并没有占用 这是需要配置么 |
 | 9 jhaohai 2016-11-20 15:23:39 +08:00 via iPhone 既然是日志那就用 es 吧 |
 | 11 realpg PRO 2G 内存…… DDR3 REG 的白菜价，我们开发的测试服务器都 48G 内存…… |
| 13 realpg PRO |
 | 14 reticentfat 2016-11-20 16:49:49 +08:00 es +1 |
 | 15 neoblackcap 2016-11-20 17:54:49 +08:00 日志请上 es ，毕竟别人就是专门搞这个 |
 | 16 sopato 2016-11-20 21:25:29 +08:00 按天分表，就按时间做索引，性能应该不会下降太多的呀，上一个公司就是这么做的，感觉性能还行，除非查询的时候跨天数太多。 |
 | 17 Nexvar 2016-11-20 21:30:01 +08:00 日志不用 ELK 技术栈? |
 | 19 Tony8Finet 2016-11-21 22:21:45 +08:00 不怕死的话 PostgreSQL 9.1 起有: CREATE UNLOGGED TABLE ...; ALTER TABLE tablename SET UNLOGGED; |
| 20 Banio OP @Tony8Finet 这个啥意思 不写入数据库吗 还是不根据事务类型 |
 | 21 RangerWolf 2016-11-23 17:05:44 +08:00 为什么不可能加内存？不解~ 另外，直接程序内部进行分表，比如每小时一张表，超过 X 小时直接删除，类似这种。 还有就是，尽量批量写、 PostgreSQL 并没有听说对日志友好啊 |
| 22 Tony8Finet 2016-11-24 04:26:09 +08:00 @Banio 不产生事务类日志, 写入效能会比一般表来得快。 看一下文件: CREATE TABLE UNLOGGED If specified, the table is created as an unlogged table. Data written to unlogged tables is not written to the write-ahead log (see Chapter 29), which makes them considerably faster than ordinary tables. However, they are not crash-safe: an unlogged table is automatically truncated after a crash or unclean shutdown. |
Select Language