Linux

Linux–mo和po文件

含义:

PO 是 Portable Object (可移植对象)的缩写形式;MO 是 Machine Object (机器对象) 的缩写形式。

PO 文件是面向翻译人员的、提取于源代码的一种资源文件。当软件升级的时候,通过使用 gettext 软件包处理 PO 文件,可以在一定程度上使翻译成果得以继承,减轻翻译人员的负担。

MO 文件是面向计算机的、由 PO 文件通过 gettext 软件包编译而成的二进制文件。程序通过读取 MO 文件使自身的界面转换成用户使用的语言。

文件相互转换:

po->mo   msgfmt  abc.po -o abc.mo

mo->po msgunfmt abc.mo -o abc.po

Linux应用程序性能

本系列文章

  1. 第一部分。迭代服务器
  2. 第二部分。分叉服务器
  3. 第三部分。预分叉服务器
  4. 第四部分。线程服务器
  5. 第五部分预先线程服务器
  6. 第六部分:基于轮询的服务器
  7. 第七部分:基于epoll的服务器

Web应用程序是消费者和企业的主要内容。在用于移动和理解位的许多现有协议中,HTTP具有压倒性的思想份额。当您遇到并了解Web应用程序开发的细微差别时,大多数人可能很少关注最终运行应用程序的操作系统。Dev和Ops的分离只会让情况变得更糟。但随着DevOps文化变得普遍,开发人员负责在云中运行他们的应用程序,更好地理解后端操作系统的细节是一个明显的优势。如果您将后端部署为供个人使用或供少数并发用户使用的系统,您实际上不必费心使用Linux以及后端如何扩展。…

        

Linux 常用内核网络参数与相关问题处理

本文总结了常见的 Linux 内核参数及相关问题。修改内核参数前,您需要:

  • 从实际需要出发,最好有相关数据的支撑,若您的业务没有受到影响不建议调整内核参数。
  • 了解每一个参数的具体作用,并且同类型或版本操作系统下内核参数可能有所不同。
  • 备份 ECS 实例中的重要数据。参阅文档创建快照

Linux 常用内核网络参数

参数 描述
net.core.rmem_default 默认的 TCP 数据接收窗口大小(字节)。
net.core.rmem_max 最大的 TCP 数据接收窗口(字节)。
net.core.wmem_default 默认的 TCP 数据发送窗口大小(字节)。
net.core.wmem_max 最大的 TCP 数据发送窗口(字节)。
net.core.netdev_max_backlog 在每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目。
net.core.somaxconn 定义了系统中每一个端口最大的监听队列的长度,这是个全局的参数。
net.core.optmem_max 表示每个套接字所允许的最大缓冲区的大小。
net.ipv4.tcp_mem 确定 TCP 栈应该如何反映内存使用,每个值的单位都是内存页(通常是
                

Linux 实例常用内核网络参数介绍与常见问题处理

Linux 实例常用内核网络参数介绍与常见问题处理

KB: 41334

 ·

更新时间:2018-11-16 20:26:51

   

本文总结了常见的 Linux 内核参数及相关问题。修改内核参数前,您需要:

  • 从实际需要出发,最好有相关数据的支撑,不建议随意调整内核参数。
  • 了解参数的具体作用,且注意同类型或版本环境的内核参数可能有所不同。
  • 备份 ECS 实例中的重要数据。参阅文档创建快照

查看和修改 Linux 实例内核参数

方法一、通过 /proc/sys/ 目录

查看内核参数:使用 cat 查看对应文件的内容,例如执行命令 cat /proc/sys/net/ipv4/tcp_tw_recycle 查看 

                

linux自定义开机启动脚本

一、概述
使用IDEA生成的linux系统可执行程序.sh文件,手动启动没有问题,开机自启动踩了不少坑,网上提供的三种方法都不适合,

有一种方法是在/etc/rc.local文件中加上启动脚本的命令,我加上之后,出现如下错误

 

我猜可能是mysql服务还没有启动,导致连接请求被拒绝。

因为我一直想将生成的这个.sh文件开机自启动,但是无奈总是不尽人意,后来换个思路,通过xshell脚本来启动这个.sh文件,搞定!…

linux后台执行命令(非阻塞):&和nohup

当我们在终端或控制台工作时,可能不希望由于运行一个作业而占住了屏幕,因为可能还有更重要的事情要做,比如阅读电子邮件。对于密集访问磁盘的进程,我们更希望它能够在每天的非负荷高峰时间段运行(例如凌晨)。为了使这些进程能够在后台运行,也就是说不在终端屏幕上运行,有几种选择方法可供使用。

  • &
    当在前台运行某个作业时,终端被该作业占据;可以在命令后面加上& 实现后台运行。例如:sh test.sh &
    适合在后台运行的命令有f i n d、费时的排序及一些s h e l l脚本。在后台运行作业时要当心:需要用户交互的命令不要放在后台执行,因为这样你的机器就会在那里傻等。不过,作业在后台运行一样会将结果输出到屏幕上,干扰你的工作。如果放在后台运行的作业会产生大量的输出,最好使用下面的方法把它的输出重定向到某个文件中:
        

linux 之信号signal处理机制

最近同事的程序设计过程中用到了Linux的signal机制,从而引发了我对Linux中signal机制的思考。Signal机制在Linux中是一个非常常用的进程间通信机制,很多人在使用的时候不会考虑该机制是具体如何实现的。signal机制可以被理解成进程的软中断,因此,在实时性方面还是相对比较高的。Linux中signal机制的模型可以采用下图进行描述。

个进程都会采用一个进程控制块对其进行描述,进程控制块中设计了一个signal的位图信息,其中的每位与具体的signal相对应,这与中断机制是保持一致的。当系统中一个进程A通过signal系统调用向进程B发送signal时,设置进程B的对应signal位图,类似于触发了signal对应中断。发送signal只是“中断”触发的一个过程,具体执行会在两个阶段发生:

1、  system call返回。进程B由于调用了system call后,从内核返回用户态时需要检查他拥有的signal位图信息表,此时是一个执行点。

2、  中断返回。进程被系统中断打断之后,系统将CPU交给进程时,需要检查即将执行进程所拥有的signal位图信息表,此时也是一个执行点。

 

综上所述,signal的执行点可以理解成从内核态返回用户态时,在返回时,如果发现待执行进程存在被触发的signal,那么在离开内核态之后(也就是将CPU切换到用户模式),执行用户进程为该signal绑定的signal处理函数,从这一点上看,signal处理函数是在用户进程上下文中执行的。当执行完signal处理函数之后,再返回到用户进程被中断或者system call(软中断或者指令陷阱)打断的地方。

 

Signal机制实现的比较灵活,用户进程由于中断或者system call陷入内核之后,将断点信息都保存到了堆栈中,在内核返回用户态时,如果存在被触发的signal,那么直接将待执行的signal处理函数push到堆栈中,在CPU切换到用户模式之后,直接pop堆栈就可以执行signal处理函数并且返回到用户进程了。Signal处理函数应用了进程上下文,并且应用实际的中断模拟了进程的软中断过程。

 

最近写程序,各种bug各种错,有一回程序莫名退出,没报错,也没产生日志和core文件,貌似正常退出一样。

但又不是在程序全部走完后退出,中途莫名退出,这就叫我想到了signal,应该是某些函数错误后发送kill信号给主进程,然后退出。

现在总结下signal各种类型:

Signal
Description
SIGABRT
由调用abort函数产生,进程非正常退出
SIGALRM
用alarm函数设置的timer超时或setitimer函数设置的interval timer超时
SIGBUS
某种特定的硬件异常,通常由内存访问引起
SIGCANCEL
由Solaris Thread Library内部使用,通常不会使用
SIGCHLD
进程Terminate或Stop的时候,SIGCHLD会发送给它的父进程。缺省情况下该Signal会被忽略
SIGCONT
当被stop的进程恢复运行的时候,自动发送
SIGEMT
和实现相关的硬件异常
SIGFPE