android studio长日志打不出来 android studio错误日志

(本文阅读预计时间：7分钟)

在众多数据库中，PostgreSQL日志系统的丰富度和日志的详细程度，都是可圈可点的，在网上不少同学都在问各种PostgreSQL的问题，其实这些问题都可以在日志中找到答案，或者提交一些日志给问题的解决者，提高问题的解决速度和问题的定位准确度。

首先我们先从日志的详细度来入手，log_min_messages定义了日志的详细程度，其实我们在选择上可能会有一些纠结，纠结点在error、warning、notice这三种，大部分人可能在选择error，出错就报错误，warning也有相关选择，实际上选择不同的日志的详细度也是有相关的一些考虑。

1. 如果你对PostgreSQL本身不熟悉，测试系统可以开启notice，这样便于你去查看一些你不理解的东西并快速进行学习，如果是生产系统初始阶段可以开启warning对系统初始时期的一些问题，可能是配置上，或者系统级别的一些问题进行更深理解，如果是稳定运行一段时间的系统则可以将其调整到error方面，降低一些不必要的日志写入，对性能和空间都有帮助。这里建议大家可以使用warning来作为常规日志详细度的使用。
2. 如果有人问，在语句执行的时候，我的语句被莫名其名的kill了我怎么查出来。下面的log_min_error_statment设置的选择项就与其有关了。

例如下面的错误：

ERROR: current transaction is aborted, commands ignored until end oftransaction blockSTATEMENT: SELECT * FROM mytable WHERE id = 1 FOR UPDATE

log_min_duration_statement是对应慢查询的日志，当设置的值大于0后，则超过对应设置数字秒数的SQL语句将被记录。

这里需要考虑你的系统是olap or oltp的情况，如果设置为1秒，但你的系统里面的SQL语句经常要大于1秒，则你的日志中将大量充斥这样的SQL导致你的日志变得非常大。

说到这个MySQL的DB会觉得PostgreSQL的日志太乱了，MySQL的日志大部分是分开的，这样有利于日志的查看和分析。这里其实也建议PostgreSQL是否可以考虑将日志分开，至少分为slow log、error log、system log等等。

当然说完不足，还得说优点，让其他数据库DB们羡慕的应该就是下面的选项，你不会在任何一个数据库中，找到如此丰富选择配置。

1. log_checkpoint对当前的checkpoint的操作进行记录，通过这个信息可以有两点1)有相关的监控系统可以读这些信息，生成图标，让这些信息成为一个趋势图来对系统进行分析，并修正系统。2)也可以手工写python程序来收集信息，直接出报告或诊断。
2. log_connections用户的登陆信息
3. log_disconnections用户的断开的登陆的信息
4. log_error_verbosity记录信息的详细程度，默认default  
5. log_hostname默认记录信息中带有客户端的IP地址，不带有对方的机器名
6. log_line_prefix相当于对日志的打印的格式和信息的设置，有些监控系统对此是有要求的，请按照你安装的监控系统的要求配置此栏
7. log_lock_waits记录语句执行中的锁等待时间
8. log_statement对于什么语句进行记录，(这个与上面无关，有语句审计的时候可能需要打开这个开关进行语句的收集，不建议使用all否则对于系统的负担太重，相当于在MySQL中开启genernal log)

实际上很多人在操作PostgreSQL开始的时候，是找不到日志的。因为默认PG的日志默认是不打开的，关键的参数在logging_collector默认是off，所以安装PostgreSQL后的启动前的第一件事情就是要将这个设置变为on，好让PostgreSQL从开始就记录日志。

另外日志的定期清理方面PostgreSQL比其他的开源数据库要做得好多了，因为不少人都要自己写日志的rotate和clean up的脚本，而PostgreSQL这里不需要，你只需要在log_rotation_age中设置你要保留几天的日志，同时 log_truncate_on_rotation设置为on就可以了，这点是非常人性化的。或者你也可以根据日志的大小进行设置如何抛弃它。

说完这些，我们来看看实际当中会遇到什么问题，以一个案例：

在搭建完PostgreSQL后，系统上线前并无问题，在系统上线后第二天，有人反馈PostgreSQL的日志将系统的磁盘空间大量的占用，并且7分钟就产生一个日志文件，后续为了减少相关的日志数量的较快增长，做到如下修改：

log_rotation_size = 100MB

将日志的容量以及重置设置的更大

修改完毕后，不重新系统，直接加载后，日志的增长频率已经更改了。但日志对磁盘空间的占用问题还是没有解决。

打开日志，系统记录了大量如下信息：

罪魁祸首就是下面图中的log_statement_stats这个设置，将他打开后，系统会根据每个SQL产生一个语句性能方面的统计信息，可以想象如果将它打开可以看到每条语句在执行中的状态，duration等等信息，但这样就会产生大量的日志，经过统计次系统1秒产生1MB的日志，(此系统每秒插入上百条数据)，在关闭后问题解决。

所以看似一个日志的设置，如果不熟悉系统，也会造成类似的问题。并且在紧急的状态下，可能会用较长的时间来解决。