存档

作者存档

Stay hungry,Stay foolish

2010年7月18日 hashei 2 条评论

好久没有更新,离上一篇日志已经2月了,头一个月在专注于复习在职研究生的期末考试,后一月则出差外加偷懒。对留言里提问题的、请求帮忙的朋友说声抱歉了,看来人一旦没有了压力,大脑里的懒惰小人就一定会占到上风。就连写这篇文章,也夹杂着看了《海贼王》第十部剧场版、《lie to me》第15级、常去的博客逛了一圈、开心网转了N个帖子。

到7月22日,我工作就将整三年。刚工作的时候,都是和Windows AD域、DNS、Exchange、WSUS打交道,感觉熟悉了MCSE的内容,就能解决工作中80%的问题,所以常常不思长进。后来转而学习中间件,用了大半年的时间知道了安装、部署、调优和troubleshooting,每天不紧不慢的看看红皮书、逛逛论坛、做做实验,日子也没什么紧迫感。直到在google reader上订阅了许多牛人的博客,才知道日子混的太多了。

比如回忆未来——张宴,和我同龄,经济与贸易专业,却已是金山的系统架构师技术——支持部平台组组长,并出了一本《实战Nginx:取代Apache的高性能Web服务器》,一篇Nginx+ PHP(FastCGI)搭建胜过Apache十倍的Web服务器成为各大linux论坛都转载的文章。

天分高?未必,《我是一只IT小小鸟》里没有一个天才的故事,都是我们可以“复制”的经历。唯一的区别,就是他们做到了。豆瓣上的这篇书评我深表赞同。

      这些优秀的人的一些共同特质:

1) <读书> 他们都是在学生时代读了很多优秀的书,不管是囫囵吞枣型,还是精读的,大量的读书才有了后来质的飞跃。
2) <兴趣> 兴趣是最好的老师,这句话深有体会,真是兴趣的驱使,才能发挥一个人最大的潜能。
3) <专注> 有了兴趣这一强大的推动力,在加上专注这颗金刚钻,再难的瓷器活都可以做到至善至美。
4) <思考> 他们不论是思考技术问题,还是在人生的方向的把握的思考,都独具深度。
5) <积累> 他们注重知识很经验的积累,量变导致质变。
6) <交流> 如果说读书是自我学习实现腾飞的一只翅膀,那么与优秀的人的交流是提升自我的另外一只翅膀。
7) <分享> 分享是一种突破,没有有效的积淀,就不容易产生有价值的分享。当在前期从周围的环境、资源中不断获取之后提升了自己,这时候就是你该分享你的经验,回报这个环境的时候了。

于是接下来的日子一直在慢慢督促自己学习这些人。其实我是很幸运的,从事的工作一是适合自己,二也是充满挑战性的,学习的空间很大,而不会是可悲的“虽说有5年工作经验,其实是1年的工作经验然后重复5次”。

自从接触中间件,然后又做系统验收前的压力测试,不得不学习linux/unix下性能监控和调优的技术,于是看了《linux服务器性能调整》。压力测试结果不满意,于是看了《构建高性能Web站点》,通过动静分离,至少从前端的角度,尽可能的提升页面展示速度。公网上部署应用,也就有了安全的需求,selinux的原理与配置、log日志的审查,渗透与反渗透的技术也就不得不掌握。运营之后的报告,也提出了监控服务器、分析应用日志的要求,shell编程、sed和awk也不得不提上学习日程。

做售后工作之余,有时还会接触一些售前上的问题,比如设备的选型,那就牵涉到容量规划,《web容量规划的艺术》使我受益良多,《大话存储-网络存储系统原理精解与最佳实践》是我下一本要看的书,虽然一本书离精通存储产品还很遥远,但至少要从整体上避免整个系统中的短板。

如此种种衍生出去的学习,正好也印证了about me中的那段话“一点服务器技术、一点操作系统知识、一点数据库概念、一点中间件结构、一点编程能力、一点网络基础、一点存储原理,还要一点IT素质和经验积累。”这些是对系统工程师的要求,但没有人来教你这么多“一点”。如果自己不要求自己,将来面试工作的时候被告知lack of sth的时候一定不好受。

上面提到的成功特质中,1、2、3、6如果还算基本的话,4、5、7对我来说是难点,也应该是很多人的难点,因为网络上多的是零零碎碎的、重复的知识,系统的全面的极少。而那些写的深入的人,无一不是那个领域的专家。其实现在成为一个专家也并非难事,只要“一万个小时”就可以了,但事实是我们往往都知道自己的弱点和需要改进的地方,可当没有旁人督促的时候,总是缺乏动力去行动。

所以如果你看到这篇文章,并且赞同我的内容,又有写博客的习惯,不如交换一下友情链接,互相支持一下,既交个朋友、又多个读者。

最后用那句著名的“Stay hungry, Stay foolish“自勉。

分类: 生活感想 标签:

为JVM启用大页面支持

2010年5月22日 hashei 1 条评论

最近在看《Linux服务器性能调整》,书中第九章-Linux虚存的性能问题中提到了当代计算机体系结构都支持多种页面大小。大型页面可以改善高性能计算及内存密集型应用的性能。回想起之前看IBM developmentworks上介绍websphere调优和oracle weblogic中tuning都提到了这一点,于是想记下一笔,不过网上正好看到ken Wu已经就此总结过了,于是转贴在此。红色部分为我添加的。

转自 Ken Wu`s Blog

原文链接 JVM优化之调整大内存分页(LargePage)

本文将从内存分页的原理,如何调整分页大小两节内容,向你阐述LargePage对JVM的性能有何提升作用,并在文末点明了大内分页的副作用。OK,让我们开始吧!

内存分页大小对性能的提升原理

首先,我们需要回顾一小部分计算机组成原理,这对理解大内存分页至于JVM性能的提升是有好处的。

什么是内存分页?
我们知道,CPU是通过寻址来访问内存的。32位CPU的寻址宽度是 0~0xFFFFFFFF ,计算后得到的大小是4G,也就是说可支持的物理内存最大是4G。

但在实践过程中,碰到了这样的问题,程序需要使用4G内存,而可用物理内存小于4G,导致程序不得不降低内存占用。
为了解决此类问题,现代CPU引入了 MMU(Memory Management Unit 内存管理单元)。

MMU 的核心思想是利用虚拟地址替代物理地址,即CPU寻址时使用虚址,由 MMU 负责将虚址映射为物理地址。
MMU的引入,解决了对物理内存的限制,对程序来说,就像自己在使用4G内存一样。

内存分页(Paging)是在使用MMU的基础上,提出的一种内存管理机制。它将虚拟地址和物理地址按固定大小(4K)分割成页(page)和页帧(page frame),并保证页与页帧的大小相同。

这种机制,从数据结构上,保证了访问内存的高效,并使OS能支持非连续性的内存分配。
在程序内存不够用时,还可以将不常用的物理内存页转移到其他存储设备上,比如磁盘,这就是大家耳熟能详的虚拟内存。

在上文中提到,虚拟地址与物理地址需要通过映射,才能使CPU正常工作。
而映射就需要存储映射表。在现代CPU架构中,映射关系通常被存储在物理内存上一个被称之为页表(page table)的地方。
如下图:

28728a1e-693e-4790-ac60-98d883472ec3

从这张图中,可以清晰地看到CPU与页表,物理内存之间的交互关系。

图中的page table在现代操作系统中由全局目录(PGD)-中间目录(PMD)-页表项(PTE)三层树构成,有时候不同书上图不一样但意思一样,只是画多画少。

进一步优化,引入TLB(Translation lookaside buffer,页表寄存器缓冲)
由上一节可知,页表是被存储在内存中的。我们知道CPU通过总线访问内存,肯定慢于直接访问寄存器的。
为了进一步优化性能,现代CPU架构引入了TLB,用来缓存一部分经常访问的页表内容。
如下图:

1381be32-3fea-460c-a310-04fcb15f99e3

对比 9.6 那张图,在中间加入了TLB。

为什么要支持大内存分页?
TLB是有限的,这点毫无疑问。当超出TLB的存储极限时,就会发生 TLB miss,之后,OS就会命令CPU去访问内存上的页表。如果频繁的出现TLB miss,程序的性能会下降地很快。

为了让TLB可以存储更多的页地址映射关系,我们的做法是调大内存分页大小。

如果一个页4M,对比一个页4K,前者可以让TLB多存储1000个页地址映射关系,性能的提升是比较可观的。

调整OS和JVM内存分页

在Linux和windows下要启用大内存页,有一些限制和设置步骤。

Linux:
限制:需要2.6内核以上或2.4内核已打大内存页补丁。
确认是否支持,请在终端敲如下命令:

# cat /proc/meminfo | grep Huge
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB

如果有HugePage字样的输出内容,说明你的OS是支持大内存分页的。Hugepagesize就是默认的大内存页size。
接下来,为了让JVM可以调整大内存页size,需要设置下OS 共享内存段最大值 和 大内存页数量。

共享内存段最大值
建议这个值大于Java Heap size,这个例子里设置了4G内存。

# echo 4294967295 > /proc/sys/kernel/shmmax

注意在32位操作系统上这个值不能超过4GB

大内存页数量

# echo 154 > /proc/sys/vm/nr_hugepages

这个值一般是 Java进程占用最大内存/单个页的大小 ,比如java设置 1.5G,单个页 10M,那么数量为  1536/10 = 154。
注意:因为proc是内存FS,为了不让你的设置在重启后被冲掉,建议写个脚本放到 init 阶段(rc.local)。

更简便的方法是

echo "vm.nr_hugepages=154" >> /etc/sysctl.conf

通过下述命令来验证设置是否生效

grep HugePages_Total /proc/meminfo

结果应该是你之前设置的数值154

 

Windows:

限制:仅支持 windows server 2003 以上server版本

操作步骤:

  1. Control Panel -> Administrative Tools -> Local Security Policy
  2. Local Policies -> User Rights Assignment
  3. 双击 “Lock pages in memory”, 添加用户和组
  4. 重启电脑

注意: 需要管理员操作。

单个页大小调整

JVM启用时加参数 -XX:LargePageSizeInBytes=10m

如果JDK是在1.5 update5以前的,还需要手动加 -XX:+UseLargePages,作用是启用大内存页支持。

——————————————————————

其实除了JVM可以使用大页面提高性能,还有一种应用更符合内存密集型的场景,那就是数据库。数据库的调优中很早就有了这部分的建议。详见

Tuning and Optimizing Red Hat Enterprise Linux for Oracle 9i and 10g Databases

当中提到

In order that an Oracle database can use Huge Pages in RHEL 4, you also need to increase the ulimit parameter "memlock" for the oracle user in/etc/security/limits.conf if "max locked memory" is not unlimited or too small, see ulimit -a or ulimit -l. For example:

oracle           soft    memlock         1048576
oracle           hard    memlock         1048576

The memlock parameter specifies how much memory the oracle user can lock into its address space. Note that Huge Pages are locked in physical memory. The memlock setting is specified in KB and must match the memory size of the number of Huge Pages that Oracle should be able to allocate. So if the Oracle database should be able to use 512 Huge Pages, then memlock must be set to at least 512 * Hugepagesize, which is on my system 1048576 KB (512*1024*2). If memlock is too small, then no single Huge Page will be allocated when the Oracle database starts.

如果limits文件中有相应设置的话,需要检查一下,避免系统没有留出足够的内存(被cache、buffer占用了)

不过作者也提到了

我们生产环境大部分java应用都没调过large page。性能瓶颈也不是在jvm上。

文章里提到的优化,仅仅是实验性质的。

优化对我们来说,是一个循序渐进的过程。我们追求的是效果明显的优化方案,而不是什么都调优一把。

按我的经验,这些一般只是锦上添花而已

WebLogic如何更换64位JDK

2010年5月18日 hashei 没有评论

使用32位JDK时,JVM一般设置最大设置为1.7G,而现在服务器普遍内存都很大,当然可以通过多个server建立垂直集群来更好的利用资源,但不妨使用64位JDK。虽然WebLogic可以直接在setDomainEnv里指定JAVA_HOME来更改JDK,但肯定会遇到BEA-000438的错,原因在于缺少对应64位JDK的native io libaray(位于weblogic/server/native)。一种方式是从别处拷贝一份过来,还有一种是下载wls_generic.jar形式的安装文件,而不是已经带有JDK的。然后下载64位JDK安装(Jrockit下载),用java –jar wls_generic.jar来安装就可以了。

————————————————————————————

附一个错误分析,和native libaray相关,但并不是由于64位的关系,而是没有执行权限。

启动过程中发现

<Apr 28, 2010 6:27:15 PM GMT+08:00> <Error> <Socket> <BEA-000438> <Unable to loa
d performance pack. Using Java I/O instead
. Please ensure that a native performa
nce library is in: ‘/opt/java1.5/jre/lib/IA64N:/opt/java1.5/jre/lib/IA64N/server
:/opt/java1.5/jre/../lib/IA64N::/opt/weblogic/bea/weblogic90/server/native/hpux1
1/IPF64:/opt/weblogic/bea/weblogic90/server/native/hpux11/PA_RISC:/opt/weblogic/
bea/weblogic90/server/native/hpux11/PA_RISC/oci920_8:/usr/lib’

没有启动native io,导致系统性能低下(这里要注意HP-UX里IA64N下的是32位JDK,IA64W下的才是64位JDK),而且java io配置的值较小,产生如下报错

<Apr 28, 2010 6:15:03 PM GMT+08:00> <Warning> <Socket> <BEA-000402> <There are:
5 active sockets, but the maximum number of socket reader threads allowed by the
configuration is: 4. You may want to alter your configuration.>

在应用使用过程中从而出现

<Apr 28, 2010 6:14:10 PM GMT+08:00> <Error> <Console> <BEA-240003> <Console enco
untered the following error javax.servlet.jsp.JspException: Broken pipe (errno:3
2)
        at com.bea.console.taglib.html.tree.TreeTag.print(TreeTag.java:231)
        at com.bea.console.taglib.html.tree.TreeTag.doEndTag(TreeTag.java:192)

观察控制台的thread信息

Self-Tuning Thread Pool    
Active Execute Threads    Execute Thread Total Count    Execute Thread Idle Count    Queue Length    Pending User Request Count    Completed Request Count    Hogging Thread Count    Standby Thread Count    Throughput    Health
16    58    15    6048    0    144840    4    38    4.577865205875421    OK

排队的请求数多达6000个,导致了OutOfMemory,在JAVA堆还很空的情况下

观察发现/opt/weblogic/bea/weblogic90/server/native/hpux11/IPF32下面和native io相关的libmuxer.so没有执行权限,chmod +x 后再次启动错误信息不再出现

分类: weblogic 标签: ,

欲速则不达

2010年4月12日 hashei 1 条评论

离上次更新已经有一个半月了,这段时间在机房待的比较多,弄的我耳鸣不止,双休日又读书,所以一直懒得动笔,难得的空闲时间又在沉迷《火炬之光》(Torch Light)。博这种东西,一旦有了惰性就完了啊,今天总算打起精神,记下最近走过的几个弯路。

在Linux上安装WAS7,图形界面无法启动的问题

$ ../JDK/jre.pak/repository/package.java.jre/java/jre/bin/java setup.jar The installer is unable to run in graphical mode. Try running the installer with the -console or -silent flag.

这个问题其实是freebsdjlu做实验的时候发现的,因为我之前安装都是没问题,所以一开始觉得是安装软件的问题,没下完整或者ftp没用二进制,后来发现是缺少compat-libstdc++-33这个包。

后来去查了安装环境要求,原来需要的包很多

Preparing Red Hat Enterprise Linux 5 for installation

Platforms that support both 32-bit and 64-bit applications require both the 32-bit and 64-bit versions of the following packages:

  • compat-libstdc++-33-3.2.3-61
  • compat-db-4.2.52-5.1
  • libXp-1.0.0-8
  • libXmu-1.0.2-5
  • libXtst-1.0.1-3.1
  • pam-0.99.6.2-3.26.el5
  •  libXft-2.1.10-1.1
  • 可以参考 Installing and verifying Linux packages来安装需要的包

    而且SELinux也是需要考虑的

You should consider the following points if you have enabled Security-Enhanced Linux (SELinux) on your Red Hat Enterprise Linux Version 5 operating system.

  • If SELinux is enabled and enforced while you are installing the product from the CD, then you must mount the CD with the following option:
     -o context=system_u:object_r:textrel_shlib_t
  • If you enable SELinux after installing the product while SELinux was disabled, then the file labels will be reset when the system is rebooted. In this case, you must run the relabel_was.sh script located in app_server_root /properties/version/nif/config/script to relabel the product runtime files. Note that running the relabel_was.sh command is not necessary if you made security mode changes with the commandsetenforce, which does not required a system reboot.
    后来在一篇博客上看到这么一段

    My little poor server

    为什么一开始决定要在Windows Server 2003 64bit上安装Oracle9i呢?于是给服务器安装了Windows Server 2003 64bit操作系统。

    可是为什么硬件架构是AMD64和Intel 64呢?Oracle9i没有这两个架构的64bit版本。于是格式化了重新安装Redhat Enterprise Linux 5。

    可是又为什么不是正版的Redhat Enterprise Linux 5呢?于是格式化安装了Redhat Enterprise Linux 4 Update 2。

    可是为什么RHEL4 Update 2不能在阵列上设置MPIO呢?于是格式化安装了Redhat Enterprise Linux 4 Update 4。

    时间就这样在一遍一遍地折磨服务器和折磨群众的过程中悄然溜走,转眼就到了下班的时候,Yeah,明天再说了。
    博主在评论里的一句话道出了真理:都是在出现问题以后才去检查软硬件兼容表的,呵呵。

在IBM刀片机上安装RHEL报错

在一台IBM的刀片机(JS21,PowerPC芯片)上直接安装redhat5.5——rhel-server-5.5-ppc-dvd。安装过程中报错:

md: Autodetecting RAID arrays.

md: autorun …

md: … autorun DONE.

RAMDISK: Compressed image found at block 0

RAMDISK: ran out of compressed data

invalid compressed format (err=1)

Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

机器上原先有操作系统AIX5.3

用上面这串错误去Google的话,会得到很多不同的解释,就是说造成这个问题的原因有多种。一次次的尝试很耗费时间,最后找到了这篇文章,《IBM Installation Toolkit:在 POWER 上加载 Linux》,用文中提到的工具IBM Installation Toolkit for Linux on POWER一次就安装成功了。(因为RHEL 5.5本月头上刚发布,所以工具介绍里没有写明支持,但是安装没有问题,5.3以上都用能用这个来安装)

这个问题其实和先前那个一样,被原有的知识所误导——X86平台上IBM的ServerGuide是为安装Windows操作系统准备的,安装Linux直接用安装盘即可,上手就去做,欲速则不达。

分类: 每周精华 标签: ,

Java 类加载器的又一篇文章

2010年3月3日 hashei 2 条评论

之前写过两篇关于java类加载的文章,分别是:《WebSphere的类加载机制和故障排查》,《再谈WebSphere的类加载和故障排查》。今天在IBM网站上看到一篇《深入探讨 Java 类加载器》,分享出来炒炒冷饭。以后遇到问题的时候也能有点方向。

Java 虚拟机默认的行为就已经足够满足大多数情况的需求了。不过如果遇到了需要与类加载器进行交互的情况,而对类加载器的机制又不是很了解的话,就很容易花大量的时间去调试 ClassNotFoundExceptionNoClassDefFoundError 等异常。本文将详细介绍 Java 的类加载器,帮助读者深刻理解 Java 语言中的这个重要概念。

互联网网站的反爬虫策略浅析(转)

2010年2月28日 hashei 没有评论

很早就看过,不过那时候没网站,也就没上心,自从开了JQ公会,头两月还好,第三个月搜狗的爬虫每天就占了几G的流量,不过那时候是虚拟主机,可配置性不大。现在转到VPS,也要开始注意了。

http://robbin.javaeye.com/

互联网网站的反爬虫策略浅析

因为搜索引擎的流行,网络爬虫已经成了很普及网络技术,除了专门做搜索的Google,Yahoo,微软,百度以外,几乎每个大型门户网站都有自己的搜索引擎,大大小小叫得出来名字得就几十种,还有各种不知名的几千几万种,对于一个内容型驱动的网站来说,受到网络爬虫的光顾是不可避免的。

一些智能的搜索引擎爬虫的爬取频率比较合理,对网站资源消耗比较少,但是很多糟糕的网络爬虫,对网页爬取能力很差,经常并发几十上百个请求循环重复抓取,这种爬虫对中小型网站往往是毁灭性打击,特别是一些缺乏爬虫编写经验的程序员写出来的爬虫破坏力极强。曾经有一次我在JavaEye的日志里面发现一个User-Agent是Java的爬虫一天之内爬取了将近100万次动态请求。这是一个用JDK标准类库编写的简单爬取网页程序,由于JavaEye网站内部链接构成了回环导致程序陷入了死循环。对于JavaEye这种百万PV级别的网站来说,这种爬虫造成的访问压力会非常大,会导致网站访问速度缓慢,甚至无法访问。

此外,相当数量的的网页爬虫目的是盗取目标网站的内容。比方说JavaEye网站就曾经被两个竞争对手网站爬取论坛帖子,然后在自己的论坛里面用机器人发帖,因此这种爬虫不仅仅影响网站访问速度,而且侵犯了网站的版权。

对于一个原创内容丰富,URL结构合理易于爬取的网站来说,简直就是各种爬虫的盘中大餐,很多网站的访问流量构成当中,爬虫带来的流量要远远超过真实用户访问流量,甚至爬虫流量要高出真实流量一个数量级。像JavaEye网站虽然设置了相当严格的反爬虫策略,但是网站处理的动态请求数量仍然是真实用户访问流量的2倍。可以肯定的说,当今互联网的网络流量至少有2/3的流量爬虫带来的。因此反爬虫是一个值得网站长期探索和解决的问题。

阅读全文…

分类: 每周精华 标签: