Quantcast
Channel: linux运维小站–linux系统架构_服务器运维_Linux运维工程师工作手札
Viewing all 130 articles
Browse latest View live

mysql 5.6.x sql_mode踩过的坑

$
0
0

线上环境使用的是oracle mysql 5.5.x,现新上一台美团云主机,准备把Mysql升级到5.6.x

sql_mode坑

5.5.x sql_mode默认值为空,5.6.x默认值为STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,于是原来的程序由于sql语句不严谨,出现报错,网站无法访问。

sql_mode坑处理办法

首先想到的是修改my.cnf文件,在my.cnf配置文件中添加sql_mode=NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,保存文件,重启Mysql服务,一气呵成,本想问题应该随之而解,但是人品欠佳,进入mysql命令行查看,sql_mode值纹丝不动,利用SET命令更改倒是可以成功,但是每次重启服务以后,此配置会失效,无奈只好想其他办法。

暂时想到两种办法

一、找开发修改程序,在mysql_query函数中添加sql_mode=’NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

二、还是在Mysql服务这块解决,在Mysql启动脚本中添加–sql-mode=”NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”,保存后测试,一切ok!


移动端网络优化_移动app网络优化

$
0
0

介绍下针对移动端的网络优化,不限于 Android,同样适用于 iOS 和 H5。
这篇文章首发在微信公众号 codekk

本文为性能优化系列第四篇,目前性能调优专题已完成以下部分:
性能优化总纲——性能问题及性能调优方式
性能优化第四篇——移动网络优化
性能优化第三篇——代码优化
性能优化第二篇——布局优化
性能优化第一篇——数据库性能优化
Android 性能调优工具 TraceView
性能优化实例

一个网络请求可以简单分为连接服务器 -> 获取数据两个部分。
其中连接服务器前还包括 DNS 解析的过程;获取数据后可能会对数据进行缓存。

一、连接服务器优化策略

1. 不用域名,用 IP 直连
省去 DNS 解析过程,DNS 全名 Domain Name System,解析意指根据域名得到其对应的 IP 地址。 如 http://www.codekk.com 的域名解析结果就是 104.236.147.76。

首次域名解析一般需要几百毫秒,可通过直接向 IP 而非域名请求,节省掉这部分时间,同时可以预防域名劫持等带来的风险。

当然为了安全和扩展考虑,这个 IP 可能是一个动态更新的 IP 列表,并在 IP 不可用情况下通过域名访问。

2. 服务器合理部署
服务器多运营商多地部署,一般至少含三大运营商、南中北三地部署。

配合上面说到的动态 IP 列表,支持优先级,每次根据地域、网络类型等选择最优的服务器 IP 进行连接。

对于服务器端还可以调优服务器的 TCP 拥塞窗口大小、重传超时时间(RTO)、最大传输单元(MTU)等。

二、获取数据优化策略

1. 连接复用
节省连接建立时间,如开启 keep-alive。

Http 1.1 默认启动了 keep-alive。对于 Android 来说默认情况下 HttpURLConnection 和 HttpClient 都开启了 keep-alive。只是 2.2 之前 HttpURLConnection 存在影响连接池的 Bug,具体可见:Android HttpURLConnection 及 HttpClient 选择

2. 请求合并
即将多个请求合并为一个进行请求,比较常见的就是网页中的 CSS Image Sprites。 如果某个页面内请求过多,也可以考虑做一定的请求合并。

3. 减小请求数据大小
(1) 对于 POST 请求,Body 可以做 Gzip 压缩,如日志。

(2) 对请求头进行压缩
这个 Http 1.1 不支持,SPDY 及 Http 2.0 支持。 Http 1.1 可以通过服务端对前一个请求的请求头进行缓存,后面相同请求头用 md5 之类的 id 来表示即可。

4. CDN 缓存静态资源
缓存常见的图片、JS、CSS 等静态资源。

5. 减小返回数据大小
(1) 压缩
一般 API 数据使用 Gzip 压缩,下图是之前测试的 Gzip 压缩前后对比图。

android-http-compare

(2) 精简数据格式
如 JSON 代替 XML,WebP 代替其他图片格式。关注公众号 codekk,回复 20 查看关于 WebP 的介绍。

(3) 对于不同的设备不同网络返回不同的内容 如不同分辨率图片大小。

(4) 增量更新
需要数据更新时,可考虑增量更新。如常见的服务端进行 bsdiff,客户端进行 bspatch。

(5) 大文件下载
支持断点续传,并缓存 Http Resonse 的 ETag 标识,下次请求时带上,从而确定是否数据改变过,未改变则直接返回 304。

6. 数据缓存
缓存获取到的数据,在一定的有效时间内再次请求可以直接从缓存读取数据。

关于 Http 缓存规则 Grumoon 在 Volley 源码解析最后杂谈中有详细介绍。

三、其他优化手段

这类优化方式在性能优化系列总篇中已经有过完整介绍
1. 预取
包括预连接、预取数据。

2. 分优先级、延迟部分请求
将不重要的请求延迟,这样既可以削峰减少并发、又可以和后面类似的请求做合并。

3. 多连接
对于较大文件,如大图片、文件下载可考虑多连接。 需要控制请求的最大并发量,毕竟移动端网络受限。

四、监控

优化需要通过数据对比才能看出效果,所以监控系统必不可少,通过前后端的数据监控确定调优效果。

注:服务器部署方面的优化有参考手 Q 和 QZone 去年的技术分享。

关注微信公众号 codekk,回复 perf 可查看 性能优化资料汇总

 

转载自:http://www.trinea.cn/android/mobile-performance-optimization/

windows 10 正版激活_win10激活密匙_win10升级助手

$
0
0

Windows 10终于正式发布了。正版的Windows 7/8.1用户可以坐等推送、免费升级,参与了Windows Insider内测项目的贡献者们也可以轻松“转正”,那么其他人呢?一定要购买吗?如果我只是想尝尝鲜,该怎么激活Windows 10呢?

虽然微软一代又一代地升级着反制技术,但是道高一尺魔高一丈,激活永远不会是个问题。就在刚刚,国外高手就放出了Windows 10的激活方法,虽然不是一键式的但也很简单。

想激活Windows 10?看这里!

Windows 10安装完毕后,首先以管理员身份打开CMD命令行窗口。

专业版用户请依次输入:

slmgr /ipk W269N-WFGWX-YVC9B-4J6C9-T83GX
slmgr /skms kms.xspace.in
slmgr /ato

企业版用户请依次输入:

slmgr /ipk NPPR9-FWDCX-D2C8J-H872K-2YT43
slmgr /skms kms.xspace.in
slmgr /ato

另外还有一批其他秘钥,大家可以自行体验,部分如下:
专业版:VK7JG-NPHTM-C97JM-9MPGT-3V66T
企业版:XGVPP-NMH47-7TTHJ-W3FW7-8HV2C
教育版:YNMGQ-8RYV3-4PGQ3-C8XTP-7CFBY
专业版N:2B87N-8KFHP-DKV6R-Y2C8J-PKCKT
企业版N:WGGHN-J84D6-QYCPR-T7PJ7-X766F
教育版N:84NGF-MHBT6-FXBX8-QWJK7-DRR8H
企业版S:FWN7H-PF93Q-4GGP8-M8RF3-MDWWW
单语言版:BT79Q-G7N6G-PGBYW-4YWX6-6F4BT

目前win10的免费升级已经开放,因为手动下载win10升级补丁会比较麻烦,所以腾讯和360分别推出了win10升级助手,帮你免费轻松升级Windows10!这里就先把腾讯的win10升级助手官方下载分享给大家。

腾讯Win10升级助手官方下载:【点此进入】

一般情况下,只要是使用win7和win8的系统,微软都会在近期通过微软助手提示大家升级win10,如果你没有收到升级win10的提示,去下面的地址下载这个升级助手安装后再在系统更新里面检查更新,就可以搜到win10更新了。

http://go.microsoft.com/fwlink/?LinkId=522367

Tengine-2.1.0/2.1.1 ngx_http_concat_module访问400问题

$
0
0

Tengine-2.1.0/2.1.1 ngx_http_concat_module访问400问题

环境:Centos 5.11

nginx_concat_module的源代码文件tengine-2.1.0或者2.1.1/src/http/modules/ngx_http_concat_module.c中为application/x-javascript正常编译安装以后,ngx_http_concat_module合并js使用正常

环境:Centos 6.6

nginx_concat_module的源代码文件tengine-2.1.0或者2.1.1/src/http/modules/ngx_http_concat_module.c中为application/x-javascript正常编译安装以后,ngx_http_concat_module合并js出现400错误

解决办法:

修改nginx_concat_module的源代码文件src/http/modules/ngx_http_concat_module.c,将application/x-javascript更改为application/javascript,然后再编译安装,在Centos 6.6环境下访问出现400提示的问题解决。

nginx安装Modsecurity,实现waf功能

$
0
0

系统:centos 6.6 64位、 tengine 2.1.1, modsecurity 2.9.0

tengine : http://tengine.taobao.org/download/tengine-2.1.1.tar.gz
modsecurity for Nginx: https://www.modsecurity.org/tarball/2.9.0/modsecurity-2.9.0.tar.gz
OWASP规则集: https://github.com/SpiderLabs/owasp-modsecurity-crs

安装git

安装依赖包

# RHEL/CentOS style install
sudo yum install pcre pcre-devel zlib zlib-devel openssl openssl-devel apr apr-util-devel apr-devel libxml2 libxml2-devel

下载modsecurity for nginx 解压,进入解压后目录执行:

./autogen.sh
./configure --enable-standalone-module --disable-mlogc
make 

在编译standalone后,nginx编译时可以通过”–add-module”添加modsecurity模块:

./configure --prefix=/usr/local/webserver/nginx --user=nobody --group=nobody --with-http_stub_status_module --with-http_realip_module --with-http_concat_module --add-module=../modsecurity-2.9.0/nginx/modsecurity/
make && make install
nginx modsecurity模块

nginx modsecurity模块安装成功

modsecurity倾向于过滤和阻止web危险,之所以强大就在于规则,OWASP提供的规则是于社区志愿者维护的,被称为核心规则CRS(corerules),规则可靠强大,当然也可以自定义规则来满足各种需求。

下载OWASP规则

git clone https://github.com/SpiderLabs/owasp-modsecurity-crs
mv owasp-modsecurity-crs /opt/tengine/conf/
cd /opt/tengine/conf/owasp-modsecurity-crs && mv modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf

启用OWASP规则

复制modsecurity源码目录下的modsecurity.conf-recommended和unicode.mapping到nginx的conf目录下,并将modsecurity.conf-recommended重新命名为modsecurity.conf。
编辑modsecurity.conf 文件,将SecRuleEngine设置为 on
owasp-modsecurity-crs下有很多存放规则的文件夹,例如base_rules、experimental_rules、optional_rules、slr_rules,里面的规则按需要启用,需要启用的规则使用Include进来即可。
Include owasp-modsecurity-crs/modsecurity_crs_10_setup.conf
Include owasp-modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf
Include owasp-modsecurity-crs/base_rules/modsecurity_crs_41_xss_attacks.conf
Include owasp-modsecurity-crs/base_rules/modsecurity_crs_40_generic_attacks.conf
Include owasp-modsecurity-crs/experimental_rules/modsecurity_crs_11_dos_protection.conf
Include owasp-modsecurity-crs/experimental_rules/modsecurity_crs_11_brute_force.conf
Include owasp-modsecurity-crs/optional_rules/modsecurity_crs_16_session_hijacking.conf

在需要启用modsecurity的主机的location下面加入下面两行即可:
ModSecurityEnabled on;
ModSecurityConfig modsecurity.conf;

ModSecurity核心规则集(CRS)提供以下类别的保户来防止攻击。
HTTP Protection (HTTP防御) – HTTP协议和本地定义使用的detectsviolations策略。
Real-time Blacklist Lookups(实时黑名单查询) -利用第三方IP信誉。
HTTP Denial of Service Protections(HTTP的拒绝服务保护) -防御HTTP的洪水攻击和HTTP
Dos 攻击。
Common Web Attacks Protection(常见的Web攻击防护) -检测常见的Web应用程序的安全攻击。
Automation Detection(自动化检测) -检测机器人,爬虫,扫描仪和其他表面恶意活动。
Integration with AV Scanning for File Uploads(文件上传防病毒扫描) -检测通过Web应用程序上传的恶意文件。
Tracking Sensitive Data(跟踪敏感数据) -信用卡通道的使用,并阻止泄漏。
Trojan Protection(木马防护) -检测访问木马。
Identification of Application Defects (应用程序缺陷的鉴定)-应用程序的错误配置警报。
Error Detection and Hiding(错误检测和隐藏) -伪装服务器发送错误消息。

参考文章:
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Installation_for_NGINX

http://www.52os.net/articles/nginx-use-modsecurity-module-as-waf.html

 

percona-toolkit安装及使用教程

$
0
0

percona-toolkit简介
percona-toolkit是一组高级命令行工具的集合,用来执行各种通过手工执行非常复杂和麻烦的mysql和系统任务,这些任务包括:
检查master和slave数据的一致性
有效地对记录进行归档
查找重复的索引
对服务器信息进行汇总
分析来自日志和tcpdump的查询
当系统出问题的时候收集重要的系统信息
percona-toolkit源自Maatkit 和Aspersa工具,这两个工具是管理mysql的最有名的工具,现在Maatkit工具已经不维护了,请大家还是使用percona-toolkit吧!这些工具主要包括开发、性能、配置、监控、复制、系统、实用六大类,作为一个优秀的DBA,里面有的工具非常有用,如果能掌握并加以灵活应用,将能极大的提高工作效率。

percona-toolkit工具包安装

准备工作,先安装:
yum install -y perl-DBI perl-DBD-MySQL perl-CPAN perl-Time-HiRes

软件包下载 https://www.percona.com/downloads/percona-toolkit/2.2.16/tarball/percona-toolkit-2.2.16.tar.gz

软件包安装
环境 Centos 5.5 64位
percona-toolkit的编译安装方式
tar xzvf percona-toolkit-2.2.16.tar.gz
cd percona-toolkit-2.2.16
perl Makefile.PL
make
make test
make install

使用教程
pt-table-checksum [OPTIONS] [DSN]
pt-table-checksum:在主<M>上通过执行校验的查询对复制的一致性进行检查,对比主从的校验值,从而产生结果。DSN指向的是主的地址,该工具的退出状态不为零,如果发现有任何差别,或者如果出现任何警告或错误,更多信息请见官网。
不制定任何参数,会直接对本地的所有数据库的表进行检查。
pt-table-checksum -S /var/run/mysqld/mysqld.sock
pt-table-sync [OPTIONS] DSN [DSN]
pt-table-sync: 高效的同步MySQL表之间的数据,他可以做单向和双向同步的表数据。他可以同步单个表,也可以同步整个库。它不同步表结构、索引、或任何其他模式对象。所以在修复一致性之前需要保证他们表存在。
接着上面的复制情况,主和从的test1数据不一致,需要修复

开源中国今日正式挂牌 新三板首家软件众包平台

$
0
0

12月7日,注册于天津开发区的恒拓开源(天津)信息科技股份有限公司(以下简称恒拓开源)携旗下运营的开源中国社区正式在新三板挂牌,股票代码为 834415。成为国内首家以开源技术为核心的公众公司。

开源中国社区在去年开始尝试众包业务,9月推出众包平台正式进入的软件开发众包领域,正式推出了开源中国众包业务,随着恒拓开源的挂牌,新三板也迎来了首家软件众包平台。

用众包“革自己的命”

近几年,随着各行各业互联网化步伐的加快,软件开发的需求也在迅速增涨。工信部数据显示,2015年1-10月,我国软件业务收入34732亿元,同比增长16.4%。但和整个软件行业巨大的市场需求相比,传统软件外包发展却无比平缓,市场规模增长量仅达到3.6%,远低于去年同期的12.9个百分点。

究其原因,传统的软件外包行业中开发成本高、合同流程繁琐、项目周期长等门槛,让许多中小型企业团队都望而却步。

作为国内首家以开源技术做企业服务的公司,恒拓开源自2007年创立起,就一直为企业提供软件开发外包和开源技术咨询。但在企业成长的过程中,恒拓开源洞悉到互联网发展的新规律就是“去中心化、去中介化”,传统软件外包以信息的不对等、不透明作为盈利基础的商业模式必将遭遇发展瓶颈。

于是,恒拓开源开始尝试转型,“革自己的命”,将“共享经济”的模式应用在软件开发领域,用众包代替传统的外包,撬动软件开发市场。

BAT齐聚众包平台,程序员17天赚8万

作为中国互联网发展三驾马车的BAT,坐拥着一批最优秀最顶级的程序员团体,依然有“需求无法满足”的时候。在开源中国众包平台上线试运行一个多月,阿里云成为了首批用户,以悬赏的方式投放了近百万元的众包项目。随后,腾讯Bugly也与开源中国众包达成战略合作关系,通过悬赏发布了近千个项目,截止发稿时,记者了解到,百度也表达了初步的合作意向,将为众包平台提供进一步演示支持。

除了帮助软件开发需求方解决燃眉之急,开源中国众包更大的愿景是希望帮助程序员改变“工作累挣钱少”的生存现状。通过让程序员便捷地接私活,挣外快,开发者们的智慧价值达到最大化。这并不是空中楼阁,水月镜花,近日,在开源中国众包平台上,一名程序员利用闲暇时间,在17天里完成阿里云的悬赏任务,税后收入高达8万元,连阿里云的项目负责人都感叹,这可能是他见过的时薪最高的工程师了。

据了解,开源中国上线至今两个月时间,发布了近90个悬赏,项目总额超过300万元,平均报名时间只花了3.8天,平均项目结项时间11.5天,并让越来越多的程序员体会到“私活赚万金金”的甜蜜滋味。

软件开发众包的“三重门”

在国内众包理念兴起的时间不长,软件开发领域的众包更是新兴事物,一些普通的企业团队、开发者还未培养用众包做开发,通过众包接私活的意识。此外,不同于淘宝、京东等实体交易的平台,软件开发的众包过程更加复杂,标准难以统一,更容易发生纠纷。国内软件众包平台若想取得长足发展,必要跨越这“三重门”:

– 平台上是否有足够多靠谱的项目

– 是否有足够多的开发者

– 功能是否完善、技术是否强的第三方平台

在恒拓开源创始人、董事长,开源中国CEO马越看来,开源中国众包平台无疑是同时具备了这三大要素。恒拓开源8年企业级服务积累的大量项目资源,可以作为种子项目放置到平台上,确保靠谱项目的持续发包,使平台充满活力。

此外,与国内其他平台相比,开源中国众包依托开源中国社区,拥有近200万开发者注册会员的资源池,人才涵盖了多种编程语言,不同技术层面,可以保证平台接包方的人力供给。

为了解决软件众包开发标准难量化,结果难评估的问题,开源中国独创性地将云技术和众包结合在一起,打造一个名为“码云”的“云开发”平台,集成了软件开发过程中必备的环节和功能。众包要平台上进行交易的所有项目开发过程都被要求在“码云”上进行,发包商可以利用“码云”上的服务,对开发过程中每一个关键节点进行把控和监管,确保开发质量。

有了这些人力、项目、过程把控的多重保证,恒拓开源推出的开源中国软件开发众包,才真正做到了以共享经济的打破了森严的开发技术壁垒,解决了传统软件开发成本高、周期长等问题,并帮助创业团队在初期钱少、缺乏CTO、没有开发团队的情况下实现软件项目开发。

智慧交易领域的阿里巴巴

随着“互联网+”概念的提出以及“大众创业万众创新”的热潮席卷,新三板、互联网创业双双迎来了异常火爆的一年。有数据显示,截至11月10日,新三板当前挂牌公司总量为4034家,其中有2469家为今年刚在新三板挂牌。而按照行业分类来看,信息技术类挂牌企业近千家,占据了新三板约25%的席位。当越来越多的互联网企业跻身新三板时,资本市场呼唤更具特色及发展前景的新鲜血液,希望培育能与中国经济发展趋势相呼应的本土互联网公司。

业内人士分析认为,恒拓开源准入新三板,成为落实以众创、众包、众扶、众筹等新模式加快推动大众创业万众创新系列重要政策的行业引领者及新标杆,是金融资本、行业资源、互联网创业相结合的现象及事件,具极大的示范效应。

开源中国众包平台将在12月12日上线“找人”和“整包”两类模式,去满足更多的开发需求。在谈及未来众包平台的商业发展模式时,马越表示:“平台以后会收取接包方10%的平台管理费,并为有需求的发包方提供增值服务。五年内,开源中国众包要力争成为智慧交易领域的阿里巴巴”。他认为,开源中国仍需两年的所谓的破冰期。2016年,开源中国平台的交易额将达到1亿元,2017年达到4亿元,2018年达到20亿元,2019年达到100亿元。

ruby源替换成taobao的源

$
0
0
为什么有这个?

由于国内网络原因(你懂的),导致 rubygems.org 存放在 Amazon S3 上面的资源文件间歇性连接失败。所以你会与遇到 gem install rackbundle install的时候半天没有响应,具体可以用 gem install rails -V 来查看执行过程。

这是一个完整 rubygems.org 镜像,你可以用此代替官方版本,同步频率目前为15分钟一次以保证尽量与官方服务同步。
如何使用?
$ gem sources --add https://ruby.taobao.org/ --remove https://rubygems.org/
$ gem sources -l
*** CURRENT SOURCES ***

https://ruby.taobao.org
# 请确保只有 ruby.taobao.org
$ gem install rails
如果你使用 Gemfile 和 Bundle (例如:Rails 项目)

你可以用 Bundler 的 Gem 源代码镜像命令

$ bundle config mirror.https://rubygems.org https://ruby.taobao.org

这样你不用改你的 Gemfile 的 source。

source 'https://rubygems.org/'
gem 'rails', '4.1.0'
...

https://ruby.taobao.org/

携程App的网络性能优化实践

$
0
0

转载:http://www.infoq.com/cn/articles/how-ctrip-improves-app-networking-performance/
携程App的网络性能优化实践
在4月23日~25日举行的QCon全球软件开发大会(北京站)上,携程无线开发总监陈浩然分享了《移动开发网络性能优化实践》,总结了携程在App网络性能优化方面的一些实践经验。在2014年接手携程无线App的框架和基础研发工作之后,陈浩然面对的首要工作就是App客户端性能优化,尤其是网络服务性能,这是所有App优化工作的重中之重。以下为正文。
首先介绍一下携程App的网络服务架构。由于携程业务众多,开发资源导致无法全部使用Native来实现业务逻辑,因此有相当一部分频道基于Hybrid实现。网络通讯属于基础&业务框架层中基础设施的一部分,为App提供统一的网络服务:
Native端的网络服务
Native模块是携程的核心业务模块(酒店、机票、火车票、攻略等),Native模块的网络服务主要通过TCP连接实现,而非常见的Restful HTTP API那种HTTP连接,只有少数轻量级服务使HTTP接口作为补充。
TCP连接网络服务模块使用了长连接+短连接机制,即有一个长连接池保持一定数目长连接,用于减少每次服务额外的连接,服务完成后会将该连接Socket放回长连接池,继续保持连接状态(一段时间空闲后会被回收);短连接作为补充,每次服务完成后便会主动关闭连接。
TCP网络服务的Payload使用的是自定义的数据及序列化协议;HTTP服务的Payload比较简单,即常见的JSON数据格式。
Hybrid端的网络服务
Hybrid模块由于是在WebView中展示本地或者直连的H5页面,页面逻辑发起的网络服务都是通过系统WebView的HTTP请求实现的。少量业务场景(需要加密和支付等)以Hybrid桥接接口形式的Native TCP通道来完成网络服务。
下图是网络服务的部署架构图


携程App所有网络服务,无论是TCP还是HTTP都会先连接到一个API Gateway服务器。如果是TCP服务,会先连接上TCP Gateway,TCP Gateway会负责将请求通过HTTP转发到后端的SOA服务接口。HTTP Gateway的原理与之类似。TCP Gateway和HTTP Gateway的区别仅仅在客户端到服务端的连接方式不同而已。Gateway的作用除了业务请求还有流量控制和熔断。
要发现常见网络性能问题,先来看看一个网络服务做了哪些事情:
1.DNS Lookup
  2.TCP Handshake
  3.TLS Handshake
  4.TCP/HTTP Request/Response
首先会是DNS解析,然后TCP连接握手,TLS连接握手(如果有的话),连接成功后再发送TCP或HTTP请求以及收到响应。如果能够将这些过程逐一梳理并确保不会存在明显的性能问题,那么基本可以确保获得不错的网络性能。网络服务里有一个重要的性能标准,即RTT(Round-Trip Time),往返时延,它表示从发送端发送数据开始,到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认)所间隔的时间。理想情况下可以假设4G网络RTT为100ms,3G网络RTT为200ms,很容易就能计算出我们的App网络服务耗时的下限,当然还要加上服务器处理时间。
常见的网络性能问题有如下几种:

问题一:DNS问题
DNS出问题的概率其实比大家感觉的要大,首先是DNS被劫持或者失效,2015年初业内比较知名的就有Apple内部DNS问题导致App Store、iTunes Connect账户无法登录;京东因为CDN域名付费问题导致服务停摆。携程在去年11月也遇到过DNS问题,主域名被国外服务商误列入黑名单,导致主站和H5等所有站点无法访问,但是App客户端的Native服务都正常,原因后面介绍。
另一个常见问题就是DNS解析慢或者失败,例如国内中国运营商网络的DNS就很慢,一次DNS查询的耗时甚至都能赶上一次连接的耗时,尤其2G网络情况下,DNS解析失败是很常见的。因此如果直接使用DNS,对于首次网络服务请求耗时和整体服务成功率都有非常大的影响。

问题二:TCP连接问题
DNS成功后拿到IP,便可以发起TCP连接。HTTP协议的网络层也是TCP连接,因此TCP连接的成功和耗时也成为网络性能的一个因素。我们发现常见的问题有TCP端口被封(例如上海长宽对非HTTP常见端口80、8080、443的封锁),以及TCP连接超时时长问题。端口被封,直接导致无法连接;连接超时时长过短,在低速网络上可能总是无法连接成果;连接超时过长,又有可能导致用户长时间等待,用户体验差。很多时候尽快失败重新发起一次连接会很快,这也是移动网络带宽不稳定情况下的一个常见情况。

问题三:Write/Read问题
DNS Lookup和TCP连接成功后,就会开始发送Request,服务端处理后返回Response,如果是HTTP连接,业内大部分App是使用第三方SDK或者系统提供的API来实现,那么只能设置些缓存策略和超时时间。iOS上的NSURLConnection超时时间在不同版本上还有不同的定义,很多时候需要自己设置Timer来实现;如果是直接使用TCP连接实现网络服务,就要自己对读写超时时间负责,与网络连接超时时长参数类似,太小了在低速网络很容易读写失败,太大了又可能影响用户体验,因此需要非常小心地处理。
我们还遇到另一类问题,某些酒店Wi-Fi对使用非80、8080和443等常见HTTP端口的服务进行了限制,即使发送Request是正常的,服务端能够正常收到,但是Response却被酒店网络proxy或防火墙拦截,客户端最终会等待读取超时。
移动网络和传统网络另一个很大的区别是Connection Migration问题。定义一个Socket连接是四元组(客户端IP,客户端Port,服务端IP,服务端Port),当用户的网络在WIFI/4G/3G/2G类型中切换时,其客户端IP会发生变化,如果此时正在进行网络服务通讯,那么Socket连接自身已经失效,最终也会导致网络服务失败。

问题四:传输Payload过大
传的多就传的慢,如果没做过特别优化,传输Payload可能会比实际所需要的大很多,那么对于整体网络服务耗时影响非常大。

问题五:复杂的国内外网络情况
国内运营商互联和海外访问国内带宽低传输慢的问题也令人难非常头疼。
看下携程App用户的网络类型分布:


Wi-Fi用户占比已超过60%,4G用户量正接近3G用户量,2G用户在逐步减少,用户的网络越来越好。4G/3G/2G网络的带宽和延迟差别很大,而带宽和延迟是网络性能的重要指标:


针对携程App用户的网络带宽和延迟,我们采样了海内外各8个城市的数据:


注意网络带宽和延迟并没有直接相关性,带宽高不意味着延迟低,延迟再低也不可能快过光速。从上图我们可以看到海内外带宽相差很大,但是延迟基本一致。
针对上面这些问题,在网络复杂环境和国内运营商互通状况无能为力的情况下,就针对性地逐一优化,以期达到目标:连得上、连得快、传输时间短。
优化实践一:优化DNS解析和缓存
由于我们的App网络服务主要基于TCP连接,为了将DNS时间降至最低,我们内置了Server IP列表,该列表可以在App启动服务中下发更新。App启动后的首次网络服务会从Server IP列表中取一个IP地址进行TCP连接,同时DNS解析会并行进行,DNS成功后,会返回最适合用户网络的Server IP,那么这个Server IP会被加入到Server IP列表中被优先使用。
Server IP列表是有权重机制的,DNS解析返回的IP很明显具有最高的权重,每次从Server IP列表中取IP会取权重最高的IP。列表中IP权重也是动态更新的,根据连接或者服务的成功失败来动态调整,这样即使DNS解析失败,用户在使用一段时间后也会选取到适合的Server IP。
优化实践二:网络质量检测(根据网络质量来改变策略)
针对网络连接和读写操作的超时时间,我们提出了网络质量检测机制。目前做到的是根据用户是在2G/3G/4G/Wi-Fi的网络环境来设置不同的超时参数,以及网络服务的并发数量。2G/3G/4G网络环境对并发TCP连接的数量是有限制的(2G网络下运营商经常只能允许单个Host一个TCP连接),因此网络服务重要参数能够根据网络质量状况来动态设定对性能和体验都非常重要。
不过目前携程App网络00质量检测的粒度还比较粗,我们正在做的优化就是能够测算到用户当前的网络RTT,根据RTT值来设置参数,那会更加准确。Facebook App的做法是HTTP网络服务在HTTP Response的Header中下发了预估的RTT值,客户端根据这个RTT值便能够设计不同的产品和服务策略。
优化实践三:提供网络服务优先级和依赖机制
由于网络对并发TCP连接的限制,就需要能够控制不必要的网络服务数量,因此我们在通讯模块中加入了网络服务优先级和依赖机制。发送一个网络服务,可以设置它的优先级,高优先级的服务优先使用长连接, 低优先级的就是用短连接。长连接由于是从长连接池中取到的TCP连接,因此节省了TCP连接时间。
网络服务依赖机制是指可以设置数个服务的依赖关系,即主从服务。假设一个App页面要发多个服务,主服务成功的情况下,才去发子服务,如果主服务失败了,自服务就无需再关心成功或者失败,会直接被取消。如果主服务成功了,那么子服务就会自动触发。
优化实践四:提供网络服务重发机制
移动网络不稳定,如果一次网络服务失败,就立刻反馈给用户你失败了,体验并不友好。我们提供了网络服务重发机制,即当网络服务在连接失败、写Request失败、读Response失败时自动重发服务;长连接失败时就用短连接来做重发补偿,短连接服务失败时当然还是用短连接来补偿。这种机制增加了用户体验到的服务成功概率。
当然不是所有网络服务都可以重发,例如当下订单服务在读取Response失败时,就不能重发,因为下单请求可能已经到达服务器,此时重发服务可能会造成重复订单,所以我们添加了重发服务开关,业务段可以自行控制是否需要。
优化实践五:减少数据传输量
我们优化了TCP服务Payload数据的格式和序列化/反序列化算法,从自定义格式转换到了Protocol Buffer数据格式,效果非常明显。序列化/反序列算法也做了调整,如果大家使用JSON数据格式,选用一个高效的反序列化算法,针对真实业务数据进行测试,收益明显。
图片格式优化在业界已有成熟的方案,例如Facebook使用的WebP图片格式,已经被国内众多App使用。
优化实践六:优化海外网络性能
海外网络性能的优化手段主要是通过花钱,例如CDN加速,提高带宽,实现动静资源分离,对于App中的Hybrid模块优化效果非常明显。
经过上面的优化手段,携程App的网络性能从优化之初的V5.9版本到现在V6.4版本,服务成功率已经有了大幅提升,核心服务成功率都在99%以上。注意这是客户端采集的服务成功率,即用户感知到的网络服务成功率,失败量中包含了客户端无网络和服务端的错误。网络服务平均耗时下降了150-200ms。我们的目标是除2G网络外,核心业务的网络服务成功率都能够达到三个九。
数据格式优化的效果尤其明显,采用新的Protocol Buffer数据格式+Gzip压缩后的Payload大小降低了15%-45%。数据序列化耗时下降了80%-90%。
经历了这半年的网络性能优化,体会最深的就是Logging基础设施的重要性。如果我们没有完整端到端监控和统计的能力,性能优化只能是盲人摸象。Logging基础设施需要包括客户端埋点采集、服务端T+0处理、后期分析、Portal展示、自动告警等多种功能,这也不是单纯的客户端框架团队可以完成的,而需要公司多个部门合作完成。
携程基于Elastic Search开发了网络实时监控Portal,能够实时监控所有的网络服务,包括多种维度,可以跟踪到单个目标用户的所有网络请求信息。
用户的性能数据都被喷到Haddop和Hive大数据平台,我们可以轻松制定并分析网络性能KPI,例如服务成功率、服务耗时、连接成功率和连接耗时等,我们做到了在时间、网络类型、城市、长短连接、服务号等多纬度的分析。下图是我们的网络性能KPI Portal,可以查看任一服务的成功率,服务耗时、操作系统、版本等各种信息,对于某个服务的性能分析非常有用。


最后看看业界网络性能优化的新技术方向,目前最有潜力的是Google推出的SPDY和QUIC协议。


SPDY已成为HTTP/2.0 Draft,有希望成为未来HTTP协议的新标准。HTTP/2.0提供了很多诱人的特性(多路复用、请求优先级、支持服务端推送、压缩HTTP Header、强制SSL传输、对服务端程序透明等)。国内很多App包括美团、淘宝、支付宝都已经在尝试使用SPDY协议,Twitter的性能测试表明可以降低30%的网络延迟,携程也做了性能测试,由于和TCP性能差距不明显,暂未在生产上使用。
QUIC是基于UDP实现的新网络协议,由于TCP协议实现已经内置在操作系统和路由器内核中,Google无法直接改进TCP,因此基于无连接的UDP协议来设计全新协议可以获得很多好处。首先能够大幅减少连接时间,QUIC可以在发送数据前只需要0 RTT时间,而传统TCP/TLS连接至少需要1-3 RTT时间才能完成连接(即使采用Fast-Open TCP或TLS Snapshot);其次可以解决TCP Head-of-Line Blocking问题,通常前一个TCP Packet发送成功前会拥塞后面的Packet发送,而QUIC可以避免这样的问题;QUIC也有更好的移动网络环境下拥塞控制算法;新的连接方式也大幅减少了Connectiont Migration问题的影响。
随着这些新协议的逐渐成熟,相信未来能够进一步提高移动端的网络服务性能,值得大家保持关注。

Centos 下源码升级mysql 5.5.x至 5.6.x

$
0
0

环境
Centos 5.x、Centos 6.x

mysql 5.5.x to mysql 5.6.x

mysql引擎 Myisam

下载mysql 5.6.x

wget http://dev.mysql.com/get/Downloads/MySQL-5.6/
mysql-5.6.28.tar.gz/from/http://cdn.mysql.com

原来数据目录:/data/mysql

安装目录:/usr/local/webserver/mysql/

tar -zxvf mysql-5.6.28.tar.gz 
cd mysql-5.6.28
cmake . -DCMAKE_INSTALL_PREFIX=/usr/local/webserver/mysql/ -DMYSQL_DATADIR=/data/mysql/ -DMYSQL_UNIX_ADDR=/tmp/mysql.sock -DWITH_MYISAM_STORAGE_ENGINE=1 -DWITH_INNOBASE_STORAGE_ENGINE=1 -DWITH_PARTITION_STORAGE_ENGINE=1 -DWITH_FEDERATED_STORAGE_ENGINE=1  -DENABLED_LOCAL_INFILE=1 -DMYSQL_TCP_PORT=3306 -DWITH_EMBEDDED_SERVER=1 -DCMAKE_THREAD_PREFER_PTHREAD=1 -DEXTRA_CHARSETS=all -DDEFAULT_CHARSET=utf8 -DDEFAULT_COLLATION=utf8_general_ci -DWITH_DEBUG=0
make && make install 
service mysqld stop  #停掉原有MySQL服务 
cp /usr/local/webserver/mysql/support-files/my-default.cnf /etc/my.cnf  #覆盖原有的my.cnf 
 
vi /etc/my.cnf   #加入并修改以下 
basedir = /usr/local/webserver/mysql #数据库安装目录 
datadir = /data/mysql #原数据库数据目录 
skip-grant-tables #由于升级需要,跳过权限验证 
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES 中去掉STRICT_TRANS_TABLES,禁用数据严格模式 
cp /usr/local/webserver/mysql/support-files/mysql.server /etc/init.d/mysqld #覆盖mysqld服务 
service mysqld start #重启新版本MySQL 
/usr/local/webserver/mysql/bin/mysql_upgrade -uroot -p #执行表权限升级 
/usr/local/webserver/mysql/bin/mysqlcheck --all-databases -p密码 #检查所有数据库 
vi /etc/my.cnf  #去掉skip-grant-tables  
service mysqld restart #数据库升级成功

编译参数可参照MySQL官方文档:
http://dev.mysql.com/doc/refman/5.6/en/source-configuration-options.html#option_cmake_storage_engine_options

 

Nginx Google 扩展-ngx_http_google_filter_module

$
0
0

转载:https://github.com/cuber/ngx_http_google_filter_module/

# 下载扩展
git clone https://github.com/cuber/ngx_http_google_filter_module

# 下载 substitutions 扩展
git clone https://github.com/yaoweibin/ngx_http_substitutions_filter_module

编译nginx选项增加

--add-module=../ngx_http_google_filter_module
  --add-module=../ngx_http_substitutions_filter_module

基本配置方法

http配置方式

server {
  server_name <你的域名>;
  listen 80;

  resolver 8.8.8.8;
  location / {
    google on;
  }
}

https配置方式

server {
  server_name <你的域名>;
  listen 443;
 
  ssl on;
  ssl_certificate <你的证书>;
  ssl_certificate_key <你的私钥>;
 
  resolver 8.8.8.8;
  location / {
    google on;
  }
}

进阶配置方法

基本搜索

需要配置 resolver 用于域名解析

server {
  # ... 仅列举部分配置
  resolver 8.8.8.8;
  location / {
    google on;
  }
  # ...
}
谷歌学术

google_scholar 依赖于 google, 所以 google_scholar 无法独立使用.
由于谷歌学术近日升级, 强制使用 https 协议, 并且 ncr 已经支持, 所以不再需要指定谷歌学术的 tld
配置 nginx

location / {
  google on;
  google_scholar on;
}
默认语言偏好

默认的语言偏好可用 google_language 来设置, 如果没有设置, 默认使用 zh-CN (中文)

location / {
  google on;
  google_scholar on;
  # 设置成德文
  google_language "de";
}

支持的语言如下.

ar    -> 阿拉伯
bg    -> 保加利亚
ca    -> 加泰罗尼亚
zh-CN -> 中国 (简体)
zh-TW -> 中国 (繁体)
hr    -> 克罗地亚
cs    -> 捷克
da    -> 丹麦
nl    -> 荷兰
en    -> 英语
tl    -> 菲律宾
fi    -> 芬兰
fr    -> 法国
de    -> 德国
el    -> 希腊
iw    -> 希伯来
hi    -> 印地文
hu    -> 匈牙利
id    -> 印度尼西亚
it    -> 意大利
ja    -> 日本
ko    -> 朝鲜
lv    -> 拉脱维亚
lt    -> 立陶宛
no    -> 挪威
fa    -> 波斯
pl    -> 波兰
pt-BR -> 葡萄牙 (巴西)
pt-PT -> 葡萄牙 (葡萄牙)
ro    -> 罗马尼亚
ru    -> 俄罗斯
sr    -> 塞尔维亚
sk    -> 斯洛伐克
sl    -> 斯洛文尼亚
es    -> 西班牙
sv    -> 瑞典
th    -> 泰国
tr    -> 土耳其
uk    -> 乌克兰
vi    -> 越南
搜索引擎爬虫许可

任何搜索引擎爬虫都不被允许爬取 google 镜像
如下的默认 robots.txt 已经内置.

User-agent: *
Disallow: /

如果想要使用 google 自己的 robots.txt 请将 google_robots_allow 设为 on

  #...
  location / {
    google on;
    google_robots_allow on;
  }
  #...
Upstreaming

upstream 减少一次域名解析的开销, 并且通过配置多个网段的 google ip 能够一定程度上减少被 google 机器人识别程序侦测到的几率 (弹验证码).

# 可以通过如下方法获取 google ip~  dig www.google.com @8.8.8.8 +short
173.194.38.209
173.194.38.211
173.194.38.212
173.194.38.210
173.194.38.208

然后将获取到的 ip 配置如下即可

upstream www.google.com {
  server 173.194.38.209:443;
  server 173.194.38.211:443;
  server 173.194.38.212:443;
  server 173.194.38.210:443;
  server 173.194.38.208:443;
}
Proxy Protocal

默认采用 https 与后端服务器通信.
你可以使用 google_ssl_off 来强制将一些域降到 http 协议.
这个设置可以让一些需要二次转发的域通过 http 协议进行转发, 从而不再依赖 ssl 证书.

#
# 例如 'www.google.com' 按如下方式代理
# vps(hk) -> vps(us) -> google
#

#
# vps(hk) 配置
#
server {
  # ...
  location / {
    google on;
    google_ssl_off "www.google.com";
  }
  # ...
}

upstream www.google.com {
  server < vps(us) 的 ip >:80;
}

#
# vps(us) 配置
#
server {
  listen 80;
  server_name www.google.com;
  # ...
  location / {
    proxy_pass https://www.google.com;
  }
  # ...
}

Centos 7搭建NTP时间服务器

$
0
0

1. NTP简介

NTP(Network Time Protocol,网络时间协议)是用来使网络中的各个计算机时间同步的一种协议。它的用途是把计算机的时钟同步到世界协调时UTC,其精度在局域网内可达0.1ms,在互联网上绝大多数的地方其精度可以达到1-50ms。

NTP服务器就是利用NTP协议提供时间同步服务的。

2. NTP服务器安装

  1. # 系统自带ntp
  2. [root@elk~]# rpm -qa ntp
  3. ntp-4.2.6p5-22.el7.centos.1.x86_64
  4. # 如果没有就安装
  5. yum -y install ntp

3. 配置NTP服务

  1. [root@elk~]# vim /etc/ntp.conf
  2. # restrict default kod nomodify notrap nopeer noquery
  3. restrict default nomodify
  4. # nomodify客户端可以同步
  5. # 将默认时间同步源注释改用可用源
  6. # server 0.centos.pool.ntp.org iburst
  7. # server 1.centos.pool.ntp.org iburst
  8. # server 2.centos.pool.ntp.org iburst
  9. # server 3.centos.pool.ntp.org iburst
  10. server ntp1.aliyun.com
  11. server time.nist.gov

4. 启动NTP服务器

  1. # 如果计划任务有时间同步,先注释,两种用法会冲突。
  2. [root@elk~]# crontab -e
  3. #*/5 * * * * /usr/sbin/ntpdate time.nist.gov >/dev/null 2>&1
  4. [root@elk~]# systemctl start ntpd
  5. [root@elk~]# ntpq -p
  6. remote refid st t when poll reach delay offset jitter
  7. ==============================================================================
  8. *ntp1.aliyun.com 10.137.38.86 2 u 22 64 1 525.885 -42.367 0.000
  9. [root@elk~]# ntpstat
  10. synchronised to NTP server (110.75.186.247) at stratum 3
  11. time correct to within 4257 ms
  12. polling server every 64 s
  13. [root@elk~]# ntpdate 192.168.1.63
  14. 7 Dec 18:43:07 ntpdate[26950]: the NTP socket is in use, exiting
  15. [root@elk~]#firewall-cmd --add-port=123/udp
  16. [root@elk~]#firewall-cmd --list-all
  17. [root@elk~]#firewall-cmd --reload

5. 客户机时间同步

客户机要等几分钟再与新启动的ntp服务器进行时间同步,否则会提示no server suitable for synchronization found错误。

  1. [root@elk~]# ntpdate 192.168.1.63
  2. 7 Dec 18:40:16 ntpdate[1453]: step time server 192.168.1.63 offset 40.880807 sec
  3. # 将命令放入计划任务即可。

微软大爱Linux开源!SQL Server正式登陆Linux

$
0
0

很多人将微软视为开源事业的敌人,但其实微软对于开源一直是很热心的,比如之前Azure与你平台就支持了Red Hat Enterprise Linux。

今天,微软又官方宣布,数据库管理软件SQL Server也要登陆Linux系统了!

微软云计算与企业事业部执行副总裁Scott Guthrie表示,微软的长远规划是将SQL Server打造成一个横跨GNU/Linux、Windows Server系统平台的稳定数据平台。

不过,微软今天只放出了Linux SQL Server的一个内部预览版本,供早期尝鲜者和开发者体验。

  最终版则预计在2017年年中发布。
微软大爱Linux开源!SQL Server正式登陆Linux

另外,Canonical也在与微软合作将SQL Server带往Ubuntu,尽管后者其实就是Linux的一个分支,但是双方希望打造一个能在Ubuntu上获得更好体验的优化版SQL Server,但发布时间待定。

如何选择文件系统:EXT4、Btrfs 和 XFS

$
0
0

老实说,人们最不曾思考的问题之一是他们的个人电脑中使用了什么文件系统。Windows 和 Mac OS X 用户更没有理由去考虑,因为对于他们的操作系统,只有一种选择,那就是 NTFS 和 HFS+。相反,对于 Linux 系统而言,有很多种文件系统可以选择,现在默认的是广泛采用的 ext4。然而,现在也有改用一种称为 btrfs 文件系统的趋势。那是什么使得 btrfs 更优秀,其它的文件系统又是什么,什么时候我们又能看到 Linux 发行版作出改变呢?

首先让我们对文件系统以及它们真正干什么有个总体的认识,然后我们再对一些有名的文件系统做详细的比较。

文件系统是干什么的?

如果你不清楚文件系统是干什么的,一句话总结起来也非常简单。文件系统主要用于控制所有程序在不使用数据时如何存储数据、如何访问数据以及有什么其它信息(元数据)和数据本身相关,等等。听起来要编程实现并不是轻而易举的事情,实际上也确实如此。文件系统一直在改进,包括了更多的功能、更高效地完成它需要做的事情。总而言之,它是所有计算机的基本需求、但并不像听起来那么简单。

为什么要分区?

由于每个操作系统都能创建或者删除分区,很多人对分区都有模糊的认识。Linux 操作系统即便使用标准安装过程,在同一块磁盘上仍使用多个分区,这看起来很奇怪,因此需要一些解释。拥有不同分区的一个主要目的就是为了在灾难发生时能获得更好的数据安全性。

通过将硬盘划分为分区,数据会被分隔以及重组。当事故发生的时候,只有存储在被损坏分区上的数据会被破坏,很大可能上其它分区的数据能得以保留。这个原因可以追溯到 Linux 操作系统还没有日志文件系统、任何电力故障都有可能导致灾难发生的时候。

使用分区也考虑到了安全和健壮性原因,因此操作系统部分损坏并不意味着整个计算机就有风险或者会受到破坏。这也是当前采用分区的一个最重要因素。举个例子,用户创建了一些会填满磁盘的脚本、程序或者 web 应用,如果该磁盘只有一个大的分区,如果磁盘满了那么整个系统就不能工作。如果用户把数据保存在不同的分区,那么就只有那个分区会受到影响,而系统分区或者其它数据分区仍能正常运行。

记住,拥有一个日志文件系统只能在掉电或者和存储设备意外断开连接时提供数据安全性,并不能在文件系统出现坏块或者发生逻辑错误时保护数据。对于这种情况,用户可以采用廉价磁盘冗余阵列RAID:Redundant Array of Inexpensive Disks的方案。

为什么要切换文件系统?

ext4 文件系统由 ext3 文件系统改进而来,而后者又是从 ext2 文件系统改进而来。虽然 ext4 文件系统已经非常稳定,是过去几年中绝大部分发行版的默认选择,但它是基于陈旧的代码开发而来。另外, Linux 操作系统用户也需要很多 ext4 文件系统本身不提供的新功能。虽然通过某些软件能满足这种需求,但性能会受到影响,在文件系统层次做到这些能获得更好的性能。

Ext4 文件系统

ext4 还有一些明显的限制。最大文件大小是 16 tebibytes(大概是 17.6 terabytes),这比普通用户当前能买到的硬盘还要大的多。使用 ext4 能创建的最大卷/分区是 1 exbibyte(大概是 1,152,921.5 terabytes)。通过使用多种技巧, ext4 比 ext3 有很大的速度提升。类似一些最先进的文件系统,它是一个日志文件系统,意味着它会对文件在磁盘中的位置以及任何其它对磁盘的更改做记录。纵观它的所有功能,它还不支持透明压缩、重复数据删除或者透明加密。技术上支持了快照,但该功能还处于实验性阶段。

Btrfs 文件系统

btrfs 有很多不同的叫法,例如 Better FS、Butter FS 或者 B-Tree FS。它是一个几乎完全从头开发的文件系统。btrfs 出现的原因是它的开发者起初希望扩展文件系统的功能使得它包括快照、池化pooling、校验以及其它一些功能。虽然和 ext4 无关,它也希望能保留 ext4 中能使消费者和企业受益的功能,并整合额外的能使每个人,尤其是企业受益的功能。对于使用大型软件以及大规模数据库的企业,让多种不同的硬盘看起来一致的文件系统能使他们受益并且使数据整合变得更加简单。删除重复数据能降低数据实际使用的空间,当需要镜像一个单一而巨大的文件系统时使用 btrfs 也能使数据镜像变得简单。

用户当然可以继续选择创建多个分区从而无需镜像任何东西。考虑到这种情况,btrfs 能横跨多种硬盘,和 ext4 相比,它能支持 16 倍以上的磁盘空间。btrfs 文件系统一个分区最大是 16 exbibytes,最大的文件大小也是 16 exbibytes。

XFS 文件系统

XFS 文件系统是扩展文件系统extent file system的一个扩展。XFS 是 64 位高性能日志文件系统。对 XFS 的支持大概在 2002 年合并到了 Linux 内核,到了 2009 年,红帽企业版 Linux 5.4 也支持了 XFS 文件系统。对于 64 位文件系统,XFS 支持最大文件系统大小为 8 exbibytes。XFS 文件系统有一些缺陷,例如它不能压缩,删除大量文件时性能低下。目前RHEL 7.0 文件系统默认使用 XFS。

总结

不幸的是,还不知道 btrfs 什么时候能到来。官方说,其下一代文件系统仍然被归类为“不稳定”,但是如果用户下载最新版本的 Ubuntu,就可以选择安装到 btrfs 分区上。什么时候 btrfs 会被归类到 “稳定” 仍然是个谜, 直到真的认为它“稳定”之前,用户也不应该期望 Ubuntu 会默认采用 btrfs。有报道说 Fedora 18 会用 btrfs 作为它的默认文件系统,因为到了发布它的时候,应该有了 btrfs 文件系统校验器。由于还没有实现所有的功能,另外和 ext4 相比性能上也比较缓慢,btrfs 还有很多的工作要做。

那么,究竟使用哪个更好呢?尽管性能几乎相同,但 ext4 还是赢家。为什么呢?答案在于易用性以及广泛性。对于桌面或者工作站, ext4 仍然是一个很好的文件系统。由于它是默认提供的文件系统,用户可以在上面安装操作系统。同时, ext4 支持最大 1 exabytes 的卷和 16 terabytes 的文件,因此考虑到大小,它也还有很大的进步空间。

btrfs 能提供更大的高达 16 exabytes 的卷以及更好的容错,但是,到现在为止,它感觉更像是一个附加的文件系统,而部署一个集成到 Linux 操作系统的文件系统。比如,尽管 btrfs 支持不同的发行版,使用 btrfs 格式化硬盘之前先要有 btrfs-tools 工具,这意味着安装 Linux 操作系统的时候它并不是一个可选项,即便不同发行版之间会有所不同。

尽管传输速率非常重要,评价一个文件统除了文件传输速度之外还有很多因素。btrfs 有很多好用的功能,例如写复制Copy-on-Write、扩展校验、快照、清洗、自修复数据、冗余删除以及其它保证数据完整性的功能。和 ZFS 相比 btrfs 缺少 RAID-Z 功能,因此对于 btrfs, RAID 还处于实验性阶段。对于单纯的数据存储,和 ext4 相比 btrfs 似乎更加优秀,但时间会验证一切。

迄今为止,对于桌面系统而言,ext4 似乎是一个更好的选择,因为它是默认的文件系统,传输文件时也比 btrfs 更快。btrfs 当然值得尝试、但要在桌面 Linux 上完全取代 ext4 可能还需要一些时间。数据场和大存储池会揭示关于 ext4、XCF 以及 btrfs 不同的场景和差异。

如果你有不同或者其它的观点,在下面的评论框中告诉我们吧。

 

via: http://www.unixmen.com/review-ext4-vs-btrfs-vs-xfs/

作者:M.el Khamlichi 译者:ictlyh 校对:Caroline

本文由 LCTT原创编译,Linux 荣誉推出

zcat命令zcat *.tar.gz|grep 匹配到二进制文件 (标准输入)

$
0
0

来自: http://man.linuxde.net/zcat

zcat命令用于不真正解压缩文件,就能显示压缩包中文件的内容的场合。

zcat(选项)(参数)
-S:指定gzip格式的压缩包的后缀。当后缀不是标准压缩包后缀时使用此选项;
-c:将文件内容写到标注输出;
-d:执行解压缩操作;
-l:显示压缩包中文件的列表;
-L:显示软件许可信息;
-q:禁用警告信息;
-r:在目录上执行递归操作;
-t:测试压缩文件的完整性;
-V:显示指令的版本信息;
-l:更快的压缩速度;
-9:更高的压缩比。
文件:指定要显示其中文件内容的压缩包。

zcat命令使用实例

zcat压缩文件进行grep匹配的时候,如果不带上-a会遇到匹配到二进制文件 (标准输入)错误的情况

因此匹配压缩文件zcat *.tar.gz  |grep -a ""这样的写法能够保证命令的正常执行。

 


Centos 5.11升级安装gcc5.3,傻瓜式安装脚本

$
0
0

环境

[root@tiboo3 ~]# cat /etc/redhat-release
CentOS release 5.11 (Final)

编译安装gcc

#!/bin/bash
GCC_V='5.3.0'
sudo yum install -y glibc-static libstdc++-static
wget http://ftp.gnu.org/gnu/<a href="https://www.olinux.org.cn/tag/gcc" title="查看与 gcc 相关的文章"target="_blank">gcc</a>/gcc-${GCC_V}/gcc-${GCC_V}.tar.bz2  -O gcc-${GCC_V}.tar.bz2
tar jxvf gcc-${GCC_V}.tar.bz2
cd gcc-${GCC_V}
./contrib/download_prerequisites
cd ..
mkdir build_gcc${GCC_V}
cd build_gcc${GCC_V}
../gcc-${GCC_V}/configure --enable-checking=release --enable-languages=c,c++ --disable-multilib
make -j8
sudo make install
cd ..
rm -rf build_gcc${GCC_V} gcc-${GCC_V} gcc-${GCC_V}.tar.bz2

卸载旧版本

yum remove -y gcc gcc-c++
updatedb

链接新版本

cd /usr/bin/
ln -s /usr/local/bin/g++ g++
ln -s /usr/local/bin/gcc gcc

检查gcc版本

[root@tiboo3 ~]# gcc -v
 Using built-in specs.
 COLLECT_GCC=gcc
 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
 Target: x86_64-unknown-linux-gnu
 Configured with: ./configure --enable-checking=release --enable-languages=c,c++ --disable-multilib
 Thread model: posix
 gcc version 5.3.0 (GCC)

Pycharm 破解注册方式

MYSQL性能调优:官方mysqldumpslow分析Mysql slow log

$
0
0

分析慢查询日志是性能调优中获取信息的主要方式之一。

如果slow log比较小,那么可以直接使用vi等文本编辑器或less、more命令打开。但如果slow log过大,载入慢查询日志将耗费大量时间,这个时候就要考虑使用其他工具来对慢查询进行分析了。

mysql的自带工具mysqldumpslow,可以有效的帮助我们对slow log进行筛选和分析。

官方文档5.7版本地址:https://dev.mysql.com/doc/refman/5.7/en/mysqldumpslow.html
参看官方文档可以略去本文。

mysqldumpslow的使用方法如下:

MYSQL性能调优:官方mysqldumpslow分析Mysql slow log

mysqldumpslow使用

1.基本用法:
执行命令:
mysqldumpslow mysqlslow.log

结果如下:

Count: 1 Time=176.25s (176s) Lock=0.00s (0s) Rows=0.0 (0), root[root]@localhost
delete FROM `info5_tuijian` where id<N ORDER BY `id` DESC

Count: 1 Time=41.52s (41s) Lock=0.00s (0s) Rows=1.0 (1), root[root]@localhost
select SQL_CALC_FOUND_ROWS * FROM `info5_tuijian` where id <N LIMIT N

可以看到,使用mysqldumpslow工具导出的慢查询日志,比原生日志要简洁很多。结果中展示的项目有:这条语句在整个slow log中执行的次数(COUNT项),平均执行时间(TIME项),总执行时间(平均执行时间后括号中的值),平均锁定时间(LOCK项,括号中为总锁定时间),平均返回行数(括号中为总返回行数),执行语句的用户和主机名,慢查询语句。

mysqldumpslow工具导出的日志,会将数字和字符串抽象为N和S。因此如果你想看到完整的SQL语句信息,可以使用-a参数来禁用抽象值。

2.结果排序:
默认情况下,mysqldumpslow的结果是按照COUNT数倒序排列。如果你想使用其他的排序方式那么可以采用下面的参数:

  • -s t、 at: 按总查询时间 或 平均查询时间
  • -s l、 al: 按总锁定时间 或 平均锁定时间
  • -s r、 ar: 按总返回行数 或 平均返回行数
  • -s c: 按执行次数
  • -r : 倒序

3.其他常用参数

  • -g patten: 只输出匹配的语句

4.示例:
# mysqldumpslow mysql-slow.log -a -g consumeitem -s t > slow.log
这条语句将删选出含有“consumeitem”的SQL语句,禁用数字和字符串的抽象,并按照查询总时间排序。
结果如下所示:

mysql 5.6.x error log InnoDB: Error: Table “innodb_table_stats”not found解决办法

$
0
0

版本:mysql 5.6.x

错误提示:

InnoDB: Cannot open table mysql/innodb_table_stats from the internal data dictionary of InnoDB thou
gh the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve
the problem.

出现这个提示总结起来有两种情况,一、mysql自带数据库mysql中Innodb引擎表损坏,二、从Mysql 5.5.x升级至5.6.x

MySQL 5.6的ibdata1表空间包含了5个InnoDB基础表,如下:

mysql&gt; select table_name from information_schema.tables where table_schema='mysql' and engine='InnoDB';
+----------------------+
| table_name           |
+----------------------+
| innodb_index_stats   |
| <a href="https://www.olinux.org.cn/tag/innodb_table_stats" title="查看与 innodb_table_stats 相关的文章"target="_blank">innodb_table_stats</a>   |
| slave_master_info    |
| slave_relay_log_info |
| slave_worker_info    |
+----------------------+
5 rows in set (0.00 sec)

在MySQL 5.6之前,如果关闭MySQL后删除ibdata1,再重新启动MySQL的时候ibdata1会被重新创建. 但从MySQL 5.6开始,这5个表不会被重建.即使删除了ibdata1,下面的10个文件仍然保留在/data/mysql/mysql中(假如datadir = /data/mysql/):
innodb_index_stats.frm
innodb_index_stats.ibd
innodb_table_stats.frm
innodb_table_stats.ibd
slave_master_info.frm
slave_master_info.ibd
slave_relay_log_info.frm
slave_relay_log_info.ibd
slave_worker_info.frm
slave_worker_info.ibd

解决办法:删除/data/mysql/mysql/目录下5个数据表的表结构及数据文件,进入命令行中执行FLUSH TABLES;然后重新创建5个数据表,再接着查看mysql错误日志发现提示已经消失。

5个数据表的sql

CREATE TABLE IF NOT EXISTS `innodb_index_stats` (
`database_name` varchar(64) COLLATE utf8_bin NOT NULL,
`table_name` varchar(64) COLLATE utf8_bin NOT NULL,
`index_name` varchar(64) COLLATE utf8_bin NOT NULL,
`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`stat_name` varchar(64) COLLATE utf8_bin NOT NULL,
`stat_value` bigint(20) unsigned NOT NULL,
`sample_size` bigint(20) unsigned DEFAULT NULL,
`stat_description` varchar(1024) COLLATE utf8_bin NOT NULL,
PRIMARY KEY (`database_name`,`table_name`,`index_name`,`stat_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;

CREATE TABLE IF NOT EXISTS `innodb_table_stats` (
`database_name` varchar(64) COLLATE utf8_bin NOT NULL,
`table_name` varchar(64) COLLATE utf8_bin NOT NULL,
`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`n_rows` bigint(20) unsigned NOT NULL,
`clustered_index_size` bigint(20) unsigned NOT NULL,
`sum_of_other_index_sizes` bigint(20) unsigned NOT NULL,
PRIMARY KEY (`database_name`,`table_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0;

CREATE TABLE IF NOT EXISTS `slave_master_info` (
`Number_of_lines` int(10) unsigned NOT NULL COMMENT 'Number of lines in the file.',
`Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT 'The name of the master binary log currently being read from the master.',
`Master_log_pos` bigint(20) unsigned NOT NULL COMMENT 'The master log position of the last read event.',
`Host` char(64) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '' COMMENT 'The host name of the master.',
`User_name` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The user name used to connect to the master.',
`User_password` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The password used to connect to the master.',
`Port` int(10) unsigned NOT NULL COMMENT 'The network port used to connect to the master.',
`Connect_retry` int(10) unsigned NOT NULL COMMENT 'The period (in seconds) that the slave will wait before trying to reconnect to the master.',
`Enabled_ssl` tinyint(1) NOT NULL COMMENT 'Indicates whether the server supports SSL connections.',
`Ssl_ca` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The file used for the Certificate Authority (CA) certificate.',
`Ssl_capath` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The path to the Certificate Authority (CA) certificates.',
`Ssl_cert` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The name of the SSL certificate file.',
`Ssl_cipher` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The name of the cipher in use for the SSL connection.',
`Ssl_key` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The name of the SSL key file.',
`Ssl_verify_server_cert` tinyint(1) NOT NULL COMMENT 'Whether to verify the server certificate.',
`Heartbeat` float NOT NULL,
`Bind` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'Displays which interface is employed when connecting to the MySQL server',
`Ignored_server_ids` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The number of server IDs to be ignored, followed by the actual server IDs',
`Uuid` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The master server uuid.',
`Retry_count` bigint(20) unsigned NOT NULL COMMENT 'Number of reconnect attempts, to the master, before giving up.',
`Ssl_crl` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The file used for the Certificate Revocation List (CRL)',
`Ssl_crlpath` text CHARACTER SET utf8 COLLATE utf8_bin COMMENT 'The path used for Certificate Revocation List (CRL) files',
`Enabled_auto_position` tinyint(1) NOT NULL COMMENT 'Indicates whether GTIDs will be used to retrieve events from the master.',
PRIMARY KEY (`Host`,`Port`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Master Information';

CREATE TABLE IF NOT EXISTS `slave_relay_log_info` (
`Number_of_lines` int(10) unsigned NOT NULL COMMENT 'Number of lines in the file or rows in the table. Used to version table definitions.',
`Relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT 'The name of the current relay log file.',
`Relay_log_pos` bigint(20) unsigned NOT NULL COMMENT 'The relay log position of the last executed event.',
`Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT 'The name of the master binary log file from which the events in the relay log file were read.',
`Master_log_pos` bigint(20) unsigned NOT NULL COMMENT 'The master log position of the last executed event.',
`Sql_delay` int(11) NOT NULL COMMENT 'The number of seconds that the slave must lag behind the master.',
`Number_of_workers` int(10) unsigned NOT NULL,
`Id` int(10) unsigned NOT NULL COMMENT 'Internal Id that uniquely identifies this record.',
PRIMARY KEY (`Id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Relay Log Information';

CREATE TABLE IF NOT EXISTS `slave_worker_info` (
`Id` int(10) unsigned NOT NULL,
`Relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Relay_log_pos` bigint(20) unsigned NOT NULL,
`Master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Master_log_pos` bigint(20) unsigned NOT NULL,
`Checkpoint_relay_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Checkpoint_relay_log_pos` bigint(20) unsigned NOT NULL,
`Checkpoint_master_log_name` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,
`Checkpoint_master_log_pos` bigint(20) unsigned NOT NULL,
`Checkpoint_seqno` int(10) unsigned NOT NULL,
`Checkpoint_group_size` int(10) unsigned NOT NULL,
`Checkpoint_group_bitmap` blob NOT NULL,
PRIMARY KEY (`Id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 STATS_PERSISTENT=0 COMMENT='Worker Information';

什么是TTFB、TTSR、TTDC、TTFL

$
0
0

什么是TTFB呢?
1.TTFB (Time To First Byte),是最初的网络请求被发起到从服务器接收到第一个字节这段时间,它包含了 TCP连接时间,发送HTTP请求时间和获得响应消息第一个字节的时间。
注意:网页重定向越多,TTFB越高,所以要减少重定向
TTFB优化的方法有:
1.减少DNS查询
2.使用CDN
3.提早Flush
4.添加周期头

什么是TTSR呢?
2.TTSR(Time to Start Render)
TTSR-开始渲染时间,指某些非空元素开始在浏览器显示时的时间,这也是一项重要指标,即TTSR越短,用户越早浏览器中的内容,心理上的等待时间会越短。过多的CPU消耗会拖慢TTSR,所以网站中有大量图片和脚本往往会造成不良用户体验。
注意
TTSR优化:
1.优化TTFB
2.降低客户端CPU消耗,即页面加载初期不要有大脚本运行,把JS脚本放到页面下方
3.使用效率较高的CSS选择器,避免使用CSS表达式
4.避免使用CSS滤镜
前端TTSR测试脚本:

<head>
<script>
(function(){
var timeStart = + new Date,
limit = 1,
timer = setInterval(function(){
if((document.body&&document.body.scrollHeight > 0) || (limit++ == 500)){
clearInterval(timer);
console.info('TTSR:',+ new Date - timeStart,';duration:',limit);
}
},10);
})()
</script>
</head>

在页面端无法简单测试出具体的TTSR,不过可以通过模拟脚本得到大概的时间,Firefox提供了一个MozAfterPaint事件,经测试,用于TTSR并不准确,如果有MozBeforePaint事件该有多好。

什么是TTDC呢?
3.TTDC(Time to Document Complete)
TTDC-文档完成时间,指页面结束加载,可供用户进行操作的时间,等价于浏览器的onload事件触发点。TTDC是比较重要的性能优化对象,TTDC越低,页面加载速度越快,用户等待时间越短。
注意
TTDC的优化方法有:
1.优化TTFB
2.优化TTSR
3.优化首屏时间,将不必要的页面加载放到onload事件之后
TTDC前端测试:
常见性能测试平台大多使用IE浏览器的DocumentComplete事件来度量TTDC,DocumentComplete事件触发时,页面的状态应是READYSTATE_COMPLETE,所以在页面中我们可以用JS脚本判断:

var win = window,doc = document;
if(win.attachEvent || doc.hasOwnProperty('onreadystatechange')){
doc.onreadystatechange = function(){
if(doc.readyState == 'complete'){
/**
* test
do something...
*/
}
}
}else{
win.addEventListener('load',function(){
/**
* test
do something...
*/
},false);
}

什么是TTFL呢?
4.TTFL(Time to Fully Loaded)
TTFL-完全加载时间,指页面在onload之前和onload事件之后额外加载的内容所花费的时间的总和,即页面完完全全加载完毕消耗的总时间。
注意
TTFL的优化方法:
1.优化TTFB
2.优化TTSR
3.优化TTDC
4.延迟加载
5.异步加载
6.按需加载
如何优化网页首字节时间
1:看一下详情分析页面。
DNS解析:如果是 DNS 解析时间太长,那是你的域名解析服务器不好,请更换靠谱的 NS 服务器。
初始化连接:如果是初始化连接的时间太长,那是你机房的网络不好,请更换更好的机房
如果上面两个都不是。那就是你的代码性能不好,代码执行消耗的时间太长。请优化代码,或者更换更好的机器。
2:客户端t1时刻发起对于某个url的请求,经过DNS解析获取相应的IP地址后,发起对该IP地址的socket连接,在完成三次握手建立tcp连接后,客户端发送http请求信息,服务端收到请求后返回响应的内容,当客户端在t2时刻收到服务端返回内容的第一个字节,则第一字节时间=t2-t1。 第一字节的时间= DNS解析的时间+socket三次握手时间+http请求时间+第一字节返回的时间。

 

Viewing all 130 articles
Browse latest View live