我们现在有台日志服务器 总容量 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 2016-11-20 16:25:15 +08:00
2G 内存……
DDR3 REG 的白菜价,我们开发的测试服务器都 48G 内存…… |
13
realpg 2016-11-20 16:33:37 +08:00
|
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. |