前言
之前序列的问题要改成cache 1才能避免开发遇到的问题。但 cache改为1会引起性能问题吗？咱们今天来一下试试。
压测cache =1的序列
在服务器上创建一个序列，cache设为1。
CREATE SEQUENCE seq_id INCREMENT 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1;复制
使用pgbench进行压测，模拟使用1024个客户端操作序列。
[pg@test ~]$ cat s1.sql
begin;
select nextval('public.seq_id');
end;
pgbench -r -P1 -c1024 -j1024 -T 60 -f /app/pg/s1.sql -Uroot -p5432 pgbench复制
在压力测试过程中，打开另一个窗口统计pg_stat_activity视图。在运行过程中，可以发现序列的主要等待事件是LWLock buffer_content
。
查看官方文档，该等待事件的含义如下:
Buffer_content Waiting to read or write a data page in memory.
没有更详细的描述，所以我决定使用 gdb来查找会话的堆栈。
通过查看会话堆栈信息，可以发现相关函数调用堆栈。首先需要经历LWLockAcquire的过程，LWLock锁是基于SpinLock实现的一种轻量级的锁，主要提供对共享内存变量的互斥访问。然后是调用read_seq_tuple，从给定的对象中锁定页面缓冲区和找到元组。
注意这里面的LockBuffer的参数是BUFFER_LOCK_EXCLUSIVE。也就是这里是需要加独占锁的。
在我压测过程中，整体cpu和内存消耗如下：
cpu有70%消耗在us，有28%消耗在sys。实际上，这种情况比较危险。因此我认为，在大量使用序列插入的情况下，仍然需要设置 cache，不设置 cache是很危险的。所以我将 cache设为20，然后执行测试。其结果是：
没有什么变化，跟我想的不一样。看起来，即使 cache设置高了，并行序列插入也会导致 system cpu很高。将并发度减半再测试，还是没有什么改进，然后我逐渐降低，即使是并发32，也是这个效果。
于是我在脚本中加入了sleep函数，强制停0.5秒，这次system cpu下来了。
整个数据库的tps也下降了很多，此时等待事件是pgsleep。看来还是要压测程序直接猛跑导致的。
后记
在高并发性环境中，使用序列将产生LWLock buffer_content等待事件，同时消耗大量 cpu资源。无论您是cache 1或cache 100，在高并发性期间都会产生同样多的消耗。在测试期间，没有出现像Oracle调大cache就可以缓解资源消耗的情况。
