昨天服务器被人入侵了，经过排查，估计是通过Serv-U提权，然后进行控制的。原本只为方便，没想到啊。长记性了！
发现网站被挂马后，立即对服务器进行处理，恢复WEB备份。并且对系统的权限进行重新加固处理，完全卸载Serv-U，FTP工具使用Gene6 FTP Server，无论是在安全性还是在功能上都比Serv-U更胜一筹。
处理过程中，发现程序的挂马已经完全清除了，但奇怪的是还是会出现木马提示，并且程序的JS文件都无法加载。个人是感觉可能启用了IIS文档页脚，但仔细查看，发现只有几个访问量大的网站被勾选了。马上在网站总设置中取消掉 "启用文档页脚"，便处理了挂马问题。
搜索C盘，发现IIS.HTM这个文件被挂马，也就是"启用文档页脚"的设置路径中的文件。
通过构建大小为0的
2009年9月李开复离职创业，开办了创新工场。然而无论是李开复还是创新工场都显得格外低调，很少有相关新闻见诸媒体。那么成立近5个月的创新工场现在是什么样子呢？今日，网易科技独家探访了创新工场，带您参观创新工场办公区。此次探营也是创新工场自成立以来办公环境在媒体上的首度曝光。
创新工场大门
大门上的温馨提示
官方解释：
附上附件 ComputerZ_CN.zip
美国服务器提供商IXWebHosting CP9 Services 于北京时间2009-12-24 9:44:43 宕机。此次宕机影响非常严重，IXWebHosting 出动所有高级工程师紧急抢修，据说是HP的硬件出了问题导致宕机。据说官方博客统计，CP9宕机最少让web Servers、MySQL Servers、mail Servers用户等合计约4000多用户受影响。其中涉及大约20000个网站不能访问。
今天10点起床就发现挂在IXWwbhosting的10个网站全部不能访问，当时还以为给墙了。立刻和IX的工程人员取得联系才得知CP9宕机了，心才平静了下来。毕竟这都是自己的心血做出来的。
等了漫长的几个小时，CP9 Services 终于在北京时间2009-12-24 15:44:43 抢修完工。历时6消失的抢修终于尘埃落定，网站终于可以正常访问了。
以下是和IX工程员的对话：
Oleg Barannik: Welcome, my name is Oleg, please let me know how can I help you today?
you: How it? The server is not available an hour,IP:96.0.216.168
Oleg Barannik: Could you please provide the domain name?
you: SHUXIONG.NET
you: ZHAOLUNWEN.NET
Oleg Barannik: Please hold on, let me check
Oleg Barannik: I am very sorry for this recent inconvenience, please accept my sincere apologies. Our system administrators have been notified and they are doing their best to fix the problem as soon as possible. It may take some more additional time to get it fixed.
Oleg Barannik: Thank you for bearing with us. We hope for your understanding and cooperation.
Oleg Barannik: You can check the status of this issue on our status blog:
Oleg Barannik: http://status.ixwebhosting.com/2009/12/23/cp9-services-down/
you: oh,i see ,thanks
Oleg Barannik: You are welcome
Oleg Barannik: Please feel free to contact us if you need further assistance. We are available 24/7.
IXWebhosting 官方关于CP9宕机的公告：
![[转载]搞定mySQL启动就占用非常大虚拟内存](https://blog.ich8.com/wp-content/themes/weisaybox/images/random/23.jpg)
为了装mysql环境测试，装上后发现启动后mysql占用了很大的虚拟内存，达8百多兆。网上搜索了一下，得到高人指点my.ini。再也没见再详细的了..只好打开my.ini逐行的啃，虽然英文差了点，不过多少M还是看得明的^-^
更改后如下：
innodb_buffer_pool_size=576M ->256M InnoDB引擎缓冲区占了大头，首要就是拿它开刀
query_cache_size=100M ->16M 查询缓存
tmp_table_size=102M ->64M 临时表大小
key_buffer_size=256m ->32M
重启mysql服务后，虚拟内存降到200以下．
另外mysql安装目录下有几个文件：my-huge.ini 、my-large.ini、my-medium.ini…这几个是根据内存大小作的建议配置，新手在设置的时候也可以参考一下。
2G内存,针对站少,优质型的设置,试验特：
table_cache=1024 物理内存越大,设置就越大.默认为2402,调到512-1024最佳
innodb_additional_mem_pool_size=8M 默认为2M
innodb_flush_log_at_trx_commit=0 等到innodb_log_buffer_size列队满后再统一储存,默认为1
innodb_log_buffer_size=4M 默认为1M
innodb_thread_concurrency=8 你的服务器CPU有几个就设置为几,默认为8
key_buffer_size=256M 默认为218 调到128最佳
tmp_table_size=64M 默认为16M 调到64-256最挂
read_buffer_size=4M 默认为64K
read_rnd_buffer_size=16M 默认为256K
sort_buffer_size=32M 默认为256K
max_connections=1024 默认为1210
试验一：
table_cache=512或1024
innodb_additional_mem_pool_size=2M
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=1M
innodb_thread_concurrency=8 你的服务器CPU有几个就设置为几,默认为8
key_buffer_size=128M
tmp_table_size=128M
read_buffer_size=64K或128K
read_rnd_buffer_size=256K
sort_buffer_size=512K
max_connections=1024
试验二：
table_cache=512或1024
innodb_additional_mem_pool_size=8M
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=4M
innodb_thread_concurrency=8
key_buffer_size=128M
tmp_table_size=128M
read_buffer_size=4M
read_rnd_buffer_size=16M
sort_buffer_size=32M
max_connections=1024
liuct:liuct:
霸王硬上弓:
james旸爷:james旸爷:james旸爷:james19820515:
ldc:
mumusnow:
kexinlh:
最活跃的读者