小编lor*_*zor的帖子

我正在尝试为我正在开发的Rails应用程序优化PostgreSQL 9.1数据库.在postgresql.conf中我已经设置好了

log_min_duration_statement = 200

然后我使用PgBadger来分析日志文件.迄今为止占据大部分时间的声明是:

COMMIT;

我得到的信息不多于此,我对这是什么陈述感到很困惑.有谁知道我能做些什么来获得有关COMMIT查询的更多详细信息？所有其他查询显示语句中使用的变量,SELECT,UPDATE等.但不是COMMIT查询.

我们的应用程序有免费和付费版本.我们还制作品牌版本,这意味着应用程序在两个方面有所不同.

四个版本可能是:

• 该应用程序,耐克编辑.自由
• APP,耐克编辑.支付
• 该应用程序,阿迪达斯编辑.支付
• 该应用程序,阿迪达斯编辑.自由

我现在的解决方案是拥有两种构建类型,付费和免费:

  buildTypes {
        paid {
            packageNameSuffix ".paid"
        }

        free {
            packageNameSuffix ".free"
        }
    }

还有两种口味:

productFlavors{
    nike{
        packageName "com.example.theapp.nike"
    }

    adidas{
        packageName "com.example.theapp.adidas"
    }

}

应用程序的每个免费版本都使我们成为内容提供者,内容提供者,特定于每个风味 - 构建类型组合.问题是我不明白在哪里放置基于构建变体的源文件.放入/ src/nike或/ src/free的源文件将根据构建类型或风格获取.但是依赖于构建变体(类型和风格的组合)的源文件呢？

我们有一个流行的iPhone应用程序,人们互相决斗一个Wordfeud.我们今天拥有近1M注册用户.

在高峰时段,应用程序的响应时间非常长,而且还有很多时间.我们试图找到瓶颈,但是很难这样做.所有服务器上的CPU,内存和I/O都低于50%.该问题仅在高峰时段出现.

我们的设置

1 VPS with nginx (1.1.9) as load balancer
4 front servers with Ruby (1.9.3p194) on Rails (3.2.5) / Unicorn (4.3.1)
1 database server with PostgreSQL 9.1.5

数据库日志没有显示足够长的请求时间来解释nginx错误日志中显示的所有超时.

我们还尝试直接针对前端服务器构建和运行应用程序(在所有其他用户针对负载均衡器运行的高峰时段).令人惊讶的是,即使在高峰时段,绕过负载均衡器的应用也很快成为子弹.

NGINX设置

worker_processes=16
worker_connections=4096
multi_accept=on

LINUX设置

fs.file-max=13184484
net.ipv4.tcp_rmem="4096 87380 4194304"
net.ipv4.tcp_wmem="4096 16384 4194304"
net.ipv4.ip_local_port_range="32768 61000"

为什么应用程序如此快速地绕过负载均衡器？nginx作为负载均衡器可以作为瓶颈吗？有没有什么好的方法来比较nginx中的超时和独角兽的超时,看看问题所在的位置？