我们有一个功能强大的Postgres服务器(64核,384 GB RAM,16个15k SAS驱动器,RAID 10),并且在白天我们多次重建几个大型数据集,这是非常密集的.Apache和Tomcat也在同一台服务器上运行.
我们每天都会收到300次这样的警告,同时重建这些数据集,并且长时间内误差平均为2 - 5秒:
2015-01-15 12:32:53 EST [11403]: [10841-1] LOG: checkpoints are occurring too frequently (2 seconds apart)
2015-01-15 12:32:56 EST [11403]: [10845-1] LOG: checkpoints are occurring too frequently (3 seconds apart)
2015-01-15 12:32:58 EST [11403]: [10849-1] LOG: checkpoints are occurring too frequently (2 seconds apart)
2015-01-15 12:33:01 EST [11403]: [10853-1] LOG: checkpoints are occurring too frequently (3 seconds apart)
这些是相关设置:
checkpoint_completion_target 0.7
checkpoint_segments 64
checkpoint_timeout 5min
checkpoint_warning 30s
wal_block_size 8192
wal_buffers 4MB
wal_keep_segments 5000
wal_level …我们的服务器具有128GB的RAM和64个内核,在CentOS 6.3上运行Tomcat 7.0.30和Oracle jdk1.6.0_38.
每隔60分钟,我们就会看到垃圾收集时间为45-60秒.添加-XX:-UseConcMarkSweepGC将页面加载时间增加了大约10%,但将其降低到大约3秒,这是一个可接受的权衡.
我们的配置:
-Xms30g -Xmx30g -XX:PermSize=8g -XX:MaxPermSize=8g -Xss256k -XX:-UseConcMarkSweepGC
我们将堆设置为30 GB以保持32位寻址(我读到32位以上,64位寻址占用更多内存,因此您必须转到大约48 GB才能看到改进).
使用VisualGC,我可以看到Eden空间每隔30-60分钟就会循环一次,但幸存者0,幸存者1,老一代和Perm Gen的情况并不多.
我们有一个强大的服务器.我们还可以进行哪些其他优化以进一步缩短3秒的GC时间？
任何提高性能或扩展的建议？
任何其他输出或配置信息会有帮助吗？
我有一个目录,其中保存共享PHP脚本(名称是任意的,但它不是/ var /,/ usr /,或SELinux将具有特定设置的
任何内容):/ whatever/scripts /
这些脚本可以由cronjobs执行,也可以由Apache或Tomcat执行,因此输出可以包含在网页中.
SELinux拒绝允许:
type = AVC msg = audit(1363205612.276:476923):avc:拒绝{execute} for pid = 6855 comm ="sh"name ="script.php"dev = sda3 ino = 4325828 scontext = system_u:system_r:httpd_t:s0 tcontext = unconfined_u:object_r:etc_runtime_t:s0 tclass = file
type = SYSCALL msg = audit(1363205612.276:476923):arch = c000003e syscall = 59 success = no exit = -13 a0 = 2431d10 a1 = 2431d70 a2 = 24301e0 a3 = 50 items = 0 ppid = 23100 pid = 6855 auid = 4294967295 uid = …
我有一个管道分隔文件,我使用以下命令导入Postgres(9.2.8):
COPY schema.tablename FROM '/path/to/file.csv' DELIMITERS '|' CSV
它已经可靠地工作了一段时间,但只是窒息:
查询失败:错误:类型时间戳的输入语法无效:"2013年9月24日12:00:00:000AM"
这对我来说似乎是一个有效的时间戳.有什么建议？
我们有一个大表（1.6T）并删除了 60% 的记录，并且希望为操作系统和文件系统回收该空间。我们正在运行 PostgreSQL 9.4（我们一直在等待重大软件升级）。
我们需要这个空间，因为我们的空间已降至 100GB，并且当刷新物化视图时，我们的服务器空间即将耗尽。
上周末我尝试运行VACUUM(FULL, ANALYZE, VERBOSE) schema.tablename并让它运行 24 小时，但不得不取消它才能让服务器重新上线。
在删除索引后，我这个周末再次运行它（我希望这会加快速度，以便完成）。到目前为止，还没有任何输出或进展迹象。我在另一个 SSD 阵列上创建了一个表空间，并使用 将其设置为临时空间temp_tablespaces = 'name_of_other_tablespaces'，但du -chs显示它仍然是空的。
查询显示active，但由于磁盘使用量没有增加，所以感觉就像它只是坐在那里，不发出任何噪音并假装它不在那里。
这是在具有 512GB RAM 和非常快的企业级 SSD 的 RAID 10 阵列的服务器上。有没有什么方法可以取得进展并知道某些事情确实正在发生并且正在发挥作用？关于持续时间的任何猜测或其他建议？