2019-03-26我根据我们自己实际应用中遇到的情况，试着回复一下两个问题：
安小依 的问题，df -h 显示占用100%，而关闭应用程序后，再次df -h是85%，这一般是因为该应用程序还有指向已删除文件的文件指针没有关闭，典型的比如日志文件，虽然在操作系统中用rm命令删除了，在相应的目录中已经没有该文件了，但如果应用中还有对应的文件指针没有关闭，则实际硬盘空间还不会释放，而应用程序被关闭时，实际空间才会释放。问题中更像是有些apk文件或处理后文件的文件指针没有释放。这种情况也可以通过 lsof | grep deleted 来找到这些文件。
lvy的out of memory的问题，可以先用free或top看一下可用内存是否确实没有了，如果确实是没有内存了，那再去研究内存的问题；还有一种常见情况，内存是充足的，文件描述符的个数或进程数达到上限了，那就得调整 ulimit，可以通过 ulimit -a (注意要用php的用户）来查看，关注open files和max user processes，这两个默认很小，1k和4k，建议调整到加两个0.展开作者回复: 谢谢😊
7- 2019-02-01打卡day33
感恩作者带来的分享，提前祝新年快乐！作者回复: 新年快乐！
6 
2019-03-14Windows和linux有很大区别吧？如果想深入了解windows，有什么可以推荐的书吗？作者回复: Windows书籍最推荐的是《Windows Internals 7th edition》
2- 2019-02-19老师您好，我最近在生产环境遇到一个问题，centos7频繁报错tcp out of memory ，访问页面时css文件响应头200，但是响应正文为空，我猜测就是因为tcp问题，有时候又能正常返回，每次重启php fpm就能解决问题，cat /proc/net/sockstat 的时候tcp 行mem值在fpm重启前后差距很大，同时tw状态的连接也很多，alloc也很大，我该怎么去找原因？能看到每个tw状态的连接占用多少tcp 内存吗？或者怎么查询php fpm为何没有释放tcp内存？
作者回复: 可以考虑调整 tcp_max_tw_buckets、ip_conntrack_max、ip_conntrack 这些内核选项
2 
2019-06-01老师，看了您的文章，有个问题一直在困扰这我。文章所说进程不可中断状态有可能是因为等待io响应，那这里的等待io响应包括等待从套接字读取数据么？如果是包括的话对于阻塞io来讲岂不是只要有阻塞进程就一直处在不可中断状态，从而无法被kill信号杀掉？作者回复: 不包括套接字
1
2019-04-03《UNIX网络编程》提到的5种IO模型中，除了异步IO模型没有阻塞操作外，其他四种IO模型（阻塞IO、非阻塞IO、IO多路复用、信号驱动IO）都有阻塞操作。是不是可以这么理解:
同步IO一定有阻塞可能有非阻塞，
异步IO一定是非阻塞；
有阻塞一定是同步IO，
有非阻塞可能是同步IO或异步IO
求大佬解答问题展开 1 1
2019-03-01老师，今天遇见了一个问题: 系统使用 df -h 显示磁盘占用100%了，而且应用程序(这是一个不停下载 apk 文件、解压缩并分析 apk文件的应用程序)在命令行也提示磁盘空间不足了。但是，关闭应用程序后，再次 df-h 统计，却发现这次磁盘占用是 85%，释放了 15%大约150G 的空间…能大概推测出来为什么关闭应用后，磁盘空间突然多了的原因吗？作者回复: 解压缩很可疑，有没有看看这些apk解压后的大小？
1
2019-02-01老师，读文件系统的内容不会引起buffer升高吧，读块设备会引起，我做了文章的实验发现
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 1620788 0 431512 0 0 348 70 415 585 2 4 94 0 0
0 0 0 1618488 0 431948 0 0 480 0 1605 2056 1 4 96 0 0
0 0 0 1619524 0 431788 0 0 16 0 1157 1674 1 2 97 0 0
2 0 0 1499696 0 548464 0 0 116905 281 5084 7062 3 14 82 1 0
2 0 0 1495664 0 552444 0 0 4964 125 2996 4413 2 6 92 0 0
2 0 0 1329960 0 646564 0 0 34028 0 8495 10589 21 24 53 1 0
2 0 0 1152440 0 769524 0 0 142805 206 13584 16541 19 32 48 1 0
3 0 0 1112028 0 783200 0 0 44753 86 14794 20490 19 23 57 0 0
0 0 0 1050900 0 809624 0 0 36540 0 8927 13517 5 20 75 0 0
0 0 0 1050892 0 809636 0 0 0 0 1277 1879 1 2 97 0 0
0 0 0 1050632 0 809644 0 0 0 0 1344 1953 1 2 97 0 0
buffer并没有升高展开作者回复: 是的，读文件内容的时候不会的。文中指的是执行 find 命令查找文件的情景
1
2019-07-29他如果都从调用者的角度来看，阻塞和同步其实没什么区别？都是在得到响应之前没法做其他事？
2019-03-24原文：DataService 停止后，bi iowait 都降到0，说明此时的所有数据都已经在系统的缓存中了。
这里所有数据指的是 数据库文件 中的数据 是吗？不包括索引。作者回复: 嗯，数据库文件
- 2019-03-20DAY32，打卡
2019-02-20老师好，请教：目录项缓存在cache中，索引节点缓存在buffer中，这是对的吗？
还是二者都在buffer中？作者回复: 不是，buffer只是磁盘的缓存，其他都可以认为是cache
- 2019-02-11关于，阻塞、非阻塞 I/O 与同步、异步 I/O ，这个问题回答。我确认下，是不是其实是一个东西，只不过划分的角度不同罢了。是这个意思吗？
作者回复: 是的，在很多场景下都可以理解成一样的。不过要细分的话，还是有些区别（见文中内容）
2019-02-02[D32打卡]
时间过得真快，转眼专栏的五大模块已经学完了三个。😄作者回复: 👍
- 2019-02-01老师，我们的测试环境机器我从几个指标看只有系统盘每秒写的数据量比测试环境多，为什么比测试环境卡很多，进程也只是测试环境一倍而已，使用vmstat pidstat,top,发现只有线上机器进程数多一倍，io写入量是测试机器10倍，测试配置4核16G，线上32核，256G，磁盘随机读写都是79MB/s左右
测试17时50分54秒 0 1 3.85 16.61 4.86 systemd
线上05:50:51 PM 0 1 151.52 1922.47 210.85 systemd
top
top - 17:57:54 up 24 days, 6:32, 3 users, load average: 2.06, 2.07, 2.41
Tasks: 974 total, 2 running, 970 sleeping, 0 stopped, 2 zombie
%Cpu(s): 2.2 us, 4.1 sy, 0.1 ni, 65.6 id, 27.7 wa, 0.0 hi, 0.0 si, 0.3 st
KiB Mem : 16249556 total, 2730324 free, 8055928 used, 5463304 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 7338032 avail Mem
线上 top - 17:58:03 up 73 days, 8:41, 2 users, load average: 4.84, 3.40, 2.94
Tasks: 2651 total, 1 running, 2650 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.4 us, 0.5 sy, 0.0 ni, 92.9 id, 5.1 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 26385616+total, 88973160 free, 23977900 used, 15090508+buff/cache
KiB Swap: 0 total, 0 free, 0 used. 23713659+avail Mem
难道IO就是线上机器卡的原因展开作者回复: 除了CPU、内存、磁盘之外，网络也可能是个原因。另外，对 I/O，还可以用 iostat 看一下其他指标是不是有什么线索
2019-02-01老师，在工作中遇到了 Ubuntu 16.04 系统死机的问题，和性能优化并不直接相关，不过还是想问一下遇到这种问题该如何分析。我能想到的步骤是：
1. 看 /var/crash 下是否有 kernel panic 的记录；
2. 看 /var/log/syslog 下是否有应用程序异常记录；
3. 看服务器上主要的应用程序日志，是否有异常；
4. 查看是否有 coredump 文件；
5. 查看 IPMI 日志，是否有硬件异常。
有的时候这一趟下来，还是没有什么收获，请问老师有没有其他需要注意的？展开作者回复: 系统日志肯定是最有效的，一般都会留下一些线索。死机的时候，如果可以通过IPMI看到服务器的Console，那也有可能看到一些线索（比如内核中的错误或者内核栈等等）。