标签: database-tuning

我正在从SQLite切换到PostgreSQL,用于典型的Rails应用程序.

问题是PG的运行规格变得缓慢.
在SQLite上花了大约34秒,在PG上它是~76秒,这慢了2倍.

所以现在我想应用一些技术来使规范的性能与SQLite相提并论,而不需要修改代码(理想情况下只需设置连接选项,这可能是不可能的).

从头到尾有几件显而易见的事情是:

• RAM磁盘(在OSX上使用RSpec进行良好设置会很好看)
• 未记录的表(它可以应用于整个数据库,所以我没有更改所有脚本吗？)

你可能已经明白我不关心可靠性和其余的(DB在这里只是一次性的东西).
我需要充分利用PG并尽可能快地完成它.

理想情况下,最佳答案将描述这样做的技巧,设置和这些技巧的弊端.

更新: fsync = off + full_page_writes = off仅将时间减少到~65秒(〜-16秒).良好的开端,但远远没有34的目标.

更新2:我尝试使用RAM磁盘,但性能增益在误差范围内.所以似乎不值得.

更新3:* 我找到了最大的瓶颈,现在我的规格和SQLite一样快.

问题是进行截断的数据库清理.显然SQLite在那里太快了.

为了"修复"它,我在每次测试之前打开一个事务并在结束时回滚它.

约700个测试的一些数字.

• 截断:SQLite - 34s,PG - 76s.
• 交易:SQLite - 17s,PG - 18s.

SQLite的速度提高了2倍.PG的速度提高4倍.

我有一个python脚本,它应该正常工作,但我需要编写执行时间.我用谷歌搜索了我应该使用timeit但我似乎无法让它工作.

我的Python脚本如下所示:

import sys
import getopt
import timeit
import random
import os
import re
import ibm_db
import time
from string import maketrans
myfile = open("results_update.txt", "a")

for r in range(100):
    rannumber = random.randint(0, 100)

    update = "update TABLE set val = %i where MyCount >= '2010' and MyCount < '2012' and number = '250'" % rannumber
    #print rannumber

    conn = ibm_db.pconnect("dsn=myDB","usrname","secretPWD")

for r in range(5):
    print "Run %s\n" % r        
    ibm_db.execute(query_stmt)
 query_stmt = ibm_db.prepare(conn, update)

myfile.close()
ibm_db.close(conn)

我需要的是执行查询并将其写入文件所需的时间 …

我一直在网上搜索为MongoDB Java驱动程序配置MongoOptions的最佳实践,除了API之外,我还没有提出太多其他方法.这个搜索在我遇到"com.mongodb.DBPortPool $ SemaphoresOut:Out of semaphores to get db connection"错误并且通过增加连接/乘数我能够解决该问题后开始.我正在寻找为生产配置这些选项的链接或最佳实践.

2.4驱动程序的选项包括:http: //api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html

• autoConnectRetry
• connectionsPerHost
• connectTimeout
• maxWaitTime
• 了socketTimeout
• threadsAllowedToBlockForConnectionMultiplier

较新的司机有更多的选择,我也有兴趣听到这些.

如何配置MySQL数据库.我想看到所有SQL都是针对数据库运行的.

我知道你可以这样做:

• set profiling=1;
• 运行慢速查询(例如 SELECT * FROM messages WHERE fromaddress='xxx';
• SHOW PROFILES;

但这似乎只适用于在命令行上运行的东西,我希望看到运行网站的结果.

我正在使用SQL Server Profiler来确定哪些进程正在消耗SQL进程,我发现事件类Audit Logout导致了大量的读取并消耗了cpu进程.

这是正常的吗？或者我在SQL Server配置中有什么问题？

我们使用Oracle Text CTXSYS.CONTEXT索引来索引包含元信息的大约50万行.信息分布在两个表中,这两个表由索引器在运行时调用的过程(功能索引)组合在一起.

当我在本地机器(简单的双核笔记本)上运行CREATE INDEX时,索引在大约3分钟内构建.在我们的数据库服务器上运行在具有8个内核和16G内存的Solaris上,需要24小时才能为相同(完全相同)的数据创建索引.

示例代码: 这是两个表和3列的索引进纸器:

create or replace procedure docmeta_revisions_text_feeder 
    ( p_rowid in rowid , p_clob in out nocopy clob) as v_clob CLOB begin
    FOR c1 IN (select DM.DID, DM.XDESCRIB || ' ' || DM.XAUTHOR AS data
        from DOCMETA DM
        WHERE ROWID = p_rowid) 
    LOOP
        v_clob := v_clob || c1.data;
        FOR c2 IN (
            SELECT ' ' || RV.DDOCTITLE AS data
            FROM   REVISIONS RV
            WHERE  RV.DID = c1.DID)
        LOOP
            v_clob := v_clob || c2.data;
        END LOOP;
    END LOOP; …

我有一个4节点集群,每个盒子上有16个核心CPU和100 GB RAM(每个机架上有2个节点).

截至目前,所有都使用Cassandra(v2.1.4)的默认JVM设置运行.使用此设置,每个节点使用13GB RAM和30%CPU.它是一个写入繁重的集群,偶尔会删除或更新.

我是否需要调整Cassandra的JVM设置以利用更多内存？我应该考虑做些什么来进行适当的设置？

我有两个表[LogTable]和[LogTable_Cross].

下面是填充它们的架构和脚本:

 --Main Table

 CREATE TABLE [dbo].[LogTable]
    (
      [LogID] [int] NOT NULL
                    IDENTITY(1, 1) ,
      [DateSent] [datetime] NULL,
    )
 ON [PRIMARY]
GO
 ALTER TABLE [dbo].[LogTable] ADD CONSTRAINT [PK_LogTable] PRIMARY KEY CLUSTERED  ([LogID]) ON [PRIMARY]
GO
 CREATE NONCLUSTERED INDEX [IX_LogTable_DateSent] ON [dbo].[LogTable] ([DateSent] DESC) ON [PRIMARY]
GO
 CREATE NONCLUSTERED INDEX [IX_LogTable_DateSent_LogID] ON [dbo].[LogTable] ([DateSent] DESC) INCLUDE ([LogID]) ON [PRIMARY]
GO


--Cross table

 CREATE TABLE [dbo].[LogTable_Cross]
    (
      [LogID] [int] NOT NULL ,
      [UserID] [int] NOT NULL
    )
 ON [PRIMARY]
GO
 ALTER TABLE …

根据我读过的有关"exec sp_reset_connection"的信息,当存在连接池时,它出现在SQL Server Profiler跟踪数据中,从数据库中考虑从跟踪数据中删除/排除它似乎是安全的 - 或者是逻辑的调整顾问.有什么想法或反对意见吗？

有些东西我对Amazon RDS(PostrgreSQL版本)并不是很了解.有些查询需要花费大量时间来显示结果.我已设置所有相关索引(如EXPLAIN所示).所以我认为这不是由于我的架构设计.

我不使用大机器(m3.xlarge),因为大机器太贵了.我的数据库大小约为300GB.

似乎Postgres没有使用所有可用内存(仅约5GB,控制台的"可用内存"报告显示总有~10GB可用内存...).我尝试按照tune -your-postgres-rds-instance的建议调整我的"参数组" ,特别是将EFFECTIVE_CACHE_SIZE设置为70%.但它没有改变任何东西.

我可能在某个地方错了......任何想法？