無標題文檔

因闰秒造成的误差

项目中碰到 PHP 和数据库之间,计算存在时间计算误差。大致的情况为根据段时间字符串,例如

2012-12-14 00:00:00 UTC

使用 MySQL 的 UNIX_TIMESTAMP 函数以及 PHP 的 strtotime 计算得出的时间戳,大概有半分钟(差不多有28秒)的误差。

同时,比较‘诡异’的是直接使用当前时间(MySQL 中 UNIX_TIMESTAMP 不带参数,同时 PHP 直接使用 time 函数),却不存在误差( 测试脚本 )。

排除了 PHP 和 MySQL 之间因为时区设置造成的时间误差 -- 根据经验,如果是时区设置造成的时间误差,应该有几个小时不会那么少。

搜索解决问题期间扫了下 这篇帖子 ,觉得应该是 ‘闰秒’ 这玩意造成的问题。搜索 PHP 闰秒相关的配置似乎没有相关的, 不过在这里似乎找到了些答案

You also can experience this behavior if your system timezone
is with leap seconds. To avoid the problem in this case please
run query UPDATE mysql.time_zone SET Use_leap_seconds='N' 
and restart the server. Please inform us if this helps.

按照上述的步骤执行,解决了问题。

回过头来,我在工作机(Windows)上测试,发现并不起作用。研究了下, 原来闰秒也需要操作系统的支持

1、对于大多数新的 Linux 内核,在设计时它们都是支持闰
   秒的,这一点在 REHL4/5 的 2.6.x 内核中得到肯定。 
2、如果 Linux 系统没有配种某种时间同步机制(比如NTP),
   那么和闰秒无关,唯一导致的结果只是系统时间会比 UTC
   时间快一秒。 
3、Window Time Service 不支持闰秒,包括服务器和客户端。

回过头来考虑项目中碰到的这种情况,直接使用时间戳存储时间点会更精确些。最后, 提供下相关的测试脚本 ,看看你的环境是否也会有类似的问题。

-- EOF --

理解 Linux 的处理器负载均值(翻译)

原文链接: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages

你可能对于 Linux 的负载均值(load averages)已有了充分的了解。负载均值在 uptime 或者 top 命令中可以看到,它们可能会显示成这个样子:

load average: 0.09, 0.05, 0.01

很多人会这样理解负载均值:三个数分别代表不同时间段的系统平均负载(一分钟、五 分钟、以及十五分钟),它们的数字当然是越小越好。数字越高,说明服务器的负载越 大,这也可能是服务器出现某种问题的信号。

而事实不完全如此,是什么因素构成了负载均值的大小,以及如何区分它们目前的状况是 「好」还是「糟糕」?什么时候应该注意哪些不正常的数值?

回答这些问题之前,首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明, 一台只配备一块单核处理器的服务器。

行车过桥

一只单核的处理器可以形象得比喻成一条单车道。设想下,你现在需要收取这条道路的过桥 费 -- 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息,例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待,那么你可以告诉后面的司机通过。 如果车辆众多,那么需要告知他们可能需要稍等一会。

因此,需要些特定的代号表示目前的车流情况,例如:

https://friable.rocks/_/2009_11_05/890367db9819.jpg

上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。

和收过桥费的管理员一样,你当然希望你的汽车(操作)不会被焦急的等待。所以,理想状态 下,都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00,但长此以往保持这 个状态,就说明会有问题,这时候你应该会很焦急。

「所以你说的理想负荷为 1.00 ?」

嗯,这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ,有经验的系统管理员都会将这条线划在 0.70:

那么多个处理器呢?我的均值是 3.00,但是系统运行正常!

哇喔,你有四个处理器的主机?那么它的负载均值在 3.00 是很正常的。

在多处理器系统中,负载均值是基于内核的数量决定的。以 100% 负载计算,1.00 表示单个处理器,而 2.00 则说明有两个双处理器,那么 4.00 就说明主机具有四个处理器。

https://friable.rocks/_/2009_11_05/556217db9819.jpg

回到我们上面有关车辆过桥的比喻。1.00 我说过是「一条单车道的道路」。那么在单车道 1.00 情况中,说明这桥梁已经被车塞满了。而在双处理器系统中,这意味着多出了一倍的 负载,也就是说还有 50% 的剩余系统资源 -- 因为还有另外条车道可以通行。

所以,单处理器已经在负载的情况下,双处理器的负载满额的情况是 2.00,它还有一倍的资源可以利用。

多核与多处理器

先脱离下主题,我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解,一台主 机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际 情况会复杂得多,不同数量的缓存、处理器的频率等因素都可能造成性能的差异。

但即便这些因素造成的实际性能稍有不同,其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则:

审视我们自己

让我们再来看看 uptime 的输出

~ $ uptime
23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36

这是个双核处理器,从结果也说明有很多的空闲资源。实际情况是即便它的峰值会到 1.7,我也从来没有考虑过它的负载问题。

那么,怎么会有三个数字的确让人困扰。我们知道,0.65、0.42、0.36 分别说明上一分钟、最后五分钟以及最后十五分钟的系统负载均值。那么这又带来了一个问题:

其实对于这些数字我们已经谈论了很多,我认为你应该着眼于五分钟或者十五分钟的平均数 值。坦白讲,如果前一分钟的负载情况是 1.00,那么仍可以说明认定服务器情况还是正常的。 但是如果十五分钟的数值仍然保持在 1.00,那么就值得注意了(根据我的经验,这时候你应 该增加的处理器数量了)。

在 Linux 下,可以使用

cat /proc/cpuinfo

获取你系统上的每个处理器的信息。如果你只想得到数字,那么就使用下面的命令:

grep 'model name' /proc/cpuinfo | wc -l

简述 Slackware Linux 硬盘安装原理

虽然 Slackware Linux 12.1 已经出来了 ,但对于我这个懒人也懒得去折腾。前几天有台 Windows 服务器被换下,在我的忽悠下管理员答应安装 Slackware 试试看,于是揣着我心爱的移动硬盘去了冬暖夏凉的 IDC 机房。

服务器没有光驱(有我也不会用),加上硬盘安装是最快的,所以没有理由不用硬盘安装。在硬盘安装 Slackware 之前,先说说本人对于 Slackware 包机制的理解。

众所周知,Slackware 的包机制其实就是 tgz 压缩包。其实按照我个人的理解,如 installpkg 这样的程序也就是个 Shell 脚本,软件的安装除了在 /var/packages 下生成已安装的软件版本以外,就不会生成别的东西;删除某个包也是类似的操作,脚本根据文件列表删除文件,作其他任何的修改。

如此的包机制,是不会校验某个软件的库依赖机制的。但就是因为这点,Slackware 在保持 了系统足够 KISS 的同时,把更多的工作交给了用户。这也意味着为什么 Slackware 不适合新手的原因,因为他们不知道将要安装的包需要哪些运行库。

言归正传,从 Slackware 的包管理机制就可以理解 Slackware 的安装过程。首先它会从安 装光盘引导各基本的内核,通常是 /isolinux/kernel 然后此内核载入 initrd 文件,引导 系统并提供给用户 Shell 接口。顺便提一下, Busybox 是个好东西,目前 Slackware 安装环境中的大部分程序都是它的映射。

然后,在引导完基本的安装环境以后,用户执行一系列的操作(分区、格式化、配置),最后安装脚本(注意,不是程序),开始最漫长的一步,就是解压缩软件包至指定的安装路径,这就是我们通常所说的安装软件包。最后是配置相应的服务等等,这并没有不同的地方。

似乎废话有点多,根据上述所言硬盘安装最重要的两个步骤就是:如何去引导安装环境,以及去何让脚本知道软件包的位置。解决这两步,硬盘安装基本上就没有什么大的问题了。

首先,我们解决如何引导安装环境。默认的 Slackware 系统还是交给 lilo 引导(「迂腐」的 Volkerding ),个人更喜欢使用 grub 。根据上述的环境,我已经有了现成的 Windows 系统,所以先下载了份 grub for DOS ,然后让 Windows 引导 grub ,再让 grub 引导内核。

这里需要两个文件从 iso 镜像中解压出来,一个就是内核,这个当然不用说;还有一个就是 initrd,它包含了安装环境需要的脚本等等。grub 引导完毕以后,指定内核和 initrd 文件,然后引导(详细步骤在参考文档中指出)。

grub> kernel (hd0,0)/bare.i
    注,Slackware 还提供了其他几个内核镜像
grub> initrd (hd0,0)/initrd
grub> boot

这样,基本的安装环境就引导完毕了。下面可以执行在安装软件包前的一系列操作。

安装软件包前需要制定软包的位置,在 选择安装源(Source Media Selection)这个步骤中,我选择 Install from a pre-mounted directory ,手工指定安装路径。当然,再次之前得把这个 iso 文件给 mount 进来。

# mkdir /target /iso 
    注,不要重名就可以
# mount /dev/sda1 /target 
    注,/dev/sda1 是移动硬盘的相应分区位置
        可以通过查看内核输出获得

然后在可以读取 iso 文件的前提下,再 mount 这个镜像文件到另外一个目录

# mount -o loop /target/slackware-12.1-dvd.iso /iso

切换回到 setup 安装程序(ALT + F1),指定安装源为 /iso/slackware 即可继续完成安装操作。

至于引导器方面,如果没有用多系统,个人认为 lilo 已经能够满足日常的应用了。grub 有更多的选择,但是有时会有不必要的安全问题,请根据实际情况选择。

最后,有关详细的安装步骤,可以 参考 LinuxSir 上面的篇文章

PS:我的移动硬盘容量太少了,尤其是放了 Slackware 安装镜像(舍不得删)和几部「电影」(更舍不得删)以后更是捉襟见肘。哪位兄弟有实惠的移动硬盘推荐?

Slackware Linux 启动图

Slackware Linux 经典的部分之一,就是其启动脚本(有空写下注释)。看见 老外的篇文章 ,让我重新审视了其启动的详细过程。

https://friable.rocks/_/2009_11_05/1260656ecf6c.jpg

使用 Slackware 那么久,尝试着给它做点贡献。于是就有了这张启动图,可能还有很多遗漏或者错误的地方,欢迎随时指正。

最后, 大图下载在这里

回顾 /proc 目录

Linux 内核将所有的设备都抽象成文件管理。这在 Linux 开发中非常有用,比如读取和写入端口只需要文件操作就可以了。

基本上,Linux 系统下的文件类型可以划分成 普通文件、目录(是的,目录也是文件)、字符设备文件、块设备文件、符号链接文件等。具体的文件类型信息,可以 参考这里

https://friable.rocks/_/2007_11_10/1194688459.gif

很多兄弟都会发现,在根目录(「/」)下都有个名为 proc 的目录。而实际的硬盘上,却并没有此目录内容。这是因为 Linux 内核在初始化系统以后,对系统各信息生成的映射。

比如,/proc/cpuinfo 文件记录了本机的 CPU 信息。放心的 cat 一下吧,它可以认为是个文本文件。这样,无论调用哪种程序语言(当然,Javascript 可不行),只要访问这个文件的内容就可得知 CPU 信息。

类似的,比如

  1. /proc/meminfo 本机的内存信息
  2. /proc/version 内核的版本信息,甚至包含了编译日期
  3. /proc/filesystems 内核支持的文件系统列表
  4. /proc/uptime 记录了系统已经运行了多少秒
  5. ...

通过 proc 目录,还可以得知内核是否支持某项功能。比如在 proc 目录下有没 apm (「/proc/apm」)文件,即可得知内核是否支持高级电源管理等等。

最后,有关 proc 更多的内容,可以 参看这里

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 其实无所谓叫什么名字,作为码农知道取名是件很难的事情。最后想到的这个名字,其实都没啥特别的含义,系统默认的文件名而已。

作为八零后,自认为还仅存点傲娇式的幽默感,以及对平淡生活的追求和向往。 为了免得对号入座和不必要的麻烦,声明本站点所持观点仅代表个人意见,不代表自己所服务公司的立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQGdyYWNlY29kZS5jb20K | base64 -d`

文章

项目