作为linux运维，多多少少会碰见这样那样的问题或故障，从中总结经验，查找问题，汇总并分析故障的原因，这是一个Linux运维工程师良好的习惯。每一次技术的突破，都经历着，伴随着快乐，瑜伽女教练让人流鼻血可我们还是的继续努力，从中也积累了更多的经验，这就是实践给予我们的丰厚回报。
某天研发某同事找我说帮他看看他写的shell脚本，死活不执行，报错。我看了下，脚本很简单，也没有常规性的错误，报“:badinterpreter:Nosuchfileordirectory”错。
看这错，我就问他是不是在windows下编写的脚本，然后在上传到linux服务器的……果然。
在DOS/windows里，文本文件的换行符为rn，而在nix系统里则为n，所以DOS/Windows里编辑过的文本文件到了nix里，每一行都多了个^M。
cron中执行的程序有输出内容，输出内容会以邮件形式发给cron的用户，而sendmail没有启动所以就产生了/var/spool/clientmqueue目录下的那些文件，日积月累可能撑破磁盘。
某天研发某同事说10.50访问10.52memcached服务异常，让我们检查下看网络/服务/系统是否有异常。检查发现系统正常，服务正常，10.50ping10.52也正常，但10.50telnet10.52很慢。同时发现该机器的namesever是不起作用的。
3）fstab文件配置错误，如分区格式错误错误(将ntfs写成了t)、配置指令拼写错误等。
某天发现某台机器df-h已用磁盘空间为90G，而du-sh/*显示所有使用空间加起来才30G，囧。
在我们找到了这个文件之后可以通过结束进程的方式来被占用的空间：echo/proc/25575/fd/33
在tmp目录下有大量包含picture_*的临时文件，每天晚上2:30对一天前的文件进行清理。之前在crontab下跑如下脚本，但是发现脚本效率很低，每次执行时负载猛涨，影响到其他服务。
从2.14到3.65（映射地址2.141）网络不通，但是从3端的其他机器到3.65网络OK。
1）端口被占用：表面看是7080端口被占用，于是netstat-nplgrep7080看了下发现7080没有占用；
bdata1是存储格式，在INNODB类型数据状态下，ibdata1用来存储文件的数据和索引，而库名的文件夹里的那些表文件只是结构而已。
可以将表空间分成多个文件存放到不同的磁盘上（表空间文件大小不受表大小的，一个表可以分布在不同步的文件上）
所有数据和索引存放在一个文件中，则随着数据的增加，将会有一个很大的文件，虽然可以把一个大文件分成多个小文件，但是多个表及索引在表空间中混合存储，这样如果对于一个表做了大量删除操作后表空间中将有大量空隙。
对于共享表空间管理的方式下，一旦表空间被分配，就不能再回缩了。当出现临时建索引或是创建一个临时表的操作表空间扩大后，就是删除相关的表也没办法回缩那部分空间了。
表空间对应的磁盘空间可以被收回（Droptable操作自动回收表空间，如果对于删除大量数据后的表可以通过:altertabletbl_nameengine=innodb;回缩不用的空间。
如果单表增加过大，如超过100G，性能也会受到影响。在这种情况下，如果使用共享表空间可以把文件分开，但有同样有一个问题，如果访问的范围过大同样会访问多个文件，一样会比较慢。
如果使用表空间，可以考虑使用分区表的方法，在一定程度上缓解问题。此外，当启用表空间模式时，需要合理调整innodb_open_files参数的设置。