java中，生产环境服务器变慢，如何诊断处理？

生产环境应当有负责监控项目的一些系统。例如，kibana上可以查看哪些接口的响应时间比较长。数据库监控可以看到有没有慢查询，有的话去找运维要一下具体的慢查询语句，然后去分析这个慢查询产生的时间和都有哪些接口被调用了。去看这些接口的响应时间哪个能对的上。定位到对应的代码，进行优化。这个是个人认为比较常见的一种情况。

优点：

1、包管理方式。FreeBSD中你可以用不同版本的基系统，却从ports里装相同版本的应用软件。而且一次编译安装好后，pkg_create命令把

这个软件和它依赖的所有包都打包成二进制，方便在其它机器上部署或者备份。当然还可备份/usr/ports/distfiles源代码目录。

2、简单、统一。不存在发行版之间的区别，换管理员也可以轻易接手。

3、ZFS。这玩意比硬raid卡还靠谱，灵活、安全、高效。Linux没有与之在一个水平线上的东西。

4、定制内核非常简单。

缺点：

1、了解的人少虽然便于装B但不便于招人，没有RH一类的认证，驱动和应用文档也少于linux，又没商业公司的大力支持——导致一些商业公司不敢用。有时也会因为某些奇怪的硬件驱动问题导致品牌服务器无法顺利安装。这是最大的缺点。

2、我觉得版本支持周期太短，5年最理想，但这种非商业化版本要维持那么长的周期不太现实，目前的维护周期算是业界良心了。

3、Java支持较弱，导致一些应用直接排除它，比如Hadoop/oracle之类。

我现在的做法: （第一种方法）

本地写代码，完成后 push 到 bitbucket 上。

然后在测试环境 pull bitbucket上的测试分支。

测试没有问题的话，在 bitbucket 创建一个拉取请求。把测试分支和主分支合并。

在生产环境中 pull bitbucket上的主分支。

第二种方法

之前看了很多文章，有人也用这种方法。

在测试环境和生产环境中分别建 git 仓库，

然后在本地的开发完直接 push 到测试环境上测试，

然后 push 到生产环境运行。

不知道这两种方法哪个更好？我现在有点纠结在这上面。不知道哪种方式更科学效率更高呢？

总感觉我目前这种方式，有点麻烦。每次 push bitbucket 上面，然后登录测试服务器 pull 。又要在 bitbucket 合并，然后登录又要登录生产环境的服务器 pull 代码。

那如果用第二种方法的话，是不是 bitbucket 就完全没有必要了？。

另外如果用第一种方法的话，应该可以代码开发玩 push 到 bitbucket 后，如果 bitbucket 上开发分支有变化，测试环境自动同步 bitbucket 上的开发分支。 bitbucket 上的主分支有更新的话，生产环境自动同步 bitbucket 上主分支的代码。（应该用 git 的 hock 应该可以做到。）但这样做的话，是不是还是要在测试环境和生产环境的服务器上分别建立 git 仓库呢？

---