搜索到
6
篇与
的结果
-
-
centos7 安装bbr脚本 BBR（Bottleneck Bandwidth and Round-trip propagation time）是Google 提出的一种新型拥塞控制算法，可以使Linux服务器显著地提高吞吐量和减少TCP连接的延迟。Google已经开源了该算法，并提交到了Linux内核，从4.9开始，Linux内核已经用上了该算法。解决方案查看当前Centos的版本大于7.3即可cat /etc/redhat-release执行一键安装脚本wget --no-check-certificate -O /opt/bbr.sh https://github.com/teddysun/across/raw/master/bbr.sh && chmod 755 /opt/bbr.sh && /opt/bbr.sh安装完成后会提示重启系统立即重启，输入：y ，等待重启完毕失败请执行：yum install -y linux-firmware验证当前的TCP算法sysctl net.ipv4.tcp_available_congestion_control结果： net.ipv4.tcp_available_congestion_control = reno cubic bbr 输出结果包含bbr 表示成功查看BBR是否启动sysctl net.ipv4.tcp_congestion_control结果为： net.ipv4.tcp_congestion_control = bbr 查看BBR是否已经载入了系统模块lsmod | grep bbr结果为： tcp_bbr 20480 8
-
网络测压小工具webBenchmark 这是一个HTTP基准测试工具，可以用来耗尽服务器带宽或流量限额。特点：每个请求都有随机的 User-Agent可自定义请求参数中的 Referer并发线程取决于您的服务器性能。项目地址： GayHub起源这个起源于MJJ论坛刷“剑皇”的运动。简单的说就是有一天有人用阿里云OSS存放黄色视频（质量极差，不想瞎眼的就别看），被mjj发现，发了一贴。标题大概是“阿里云oss没有鉴黄？”，附带一个txt文件，包括大约350条链接。闲的没事干的就用吃灰鸡配上aria2/wget刷起来，大概刷了一两天所有链接失效。有大佬发了一个脚本：这是剑皇史上重要的转折点，从个人剑皇变成了集体剑皇，从wget、axel、aria2到专用的golang版本（本文脚本）。剑皇操作（刷流量）（鉴黄）本质就是 CC 攻击按流量计费的网站，是以恶制恶的行为。使用说明参数说明webBenchmark -c [COUNT] -s [URL] -r [REFERER] -c 整数，当前的下载线程数（默认 8）； -r 字符串，HTTP请求的 referer 参数； -s 字符串，目标链接（默认"https://baidu.com"）；LINUX:一条一条复制执行以下命令即可（注意替换参数）。wget https://github.com/maintell/webBenchmark/releases/download/0.1/webBenchmark_linux_x64 chmod +x webBenchmark_linux_x64 ./webBenchmark_linux_x64 -c 32 -s https://target.urlWindows:打开releases页面下载合适的EXE文件启动CMD命令窗口，进入程序所在目录，如下运行命令。工具的重点在于下载远程文件的过程中不会读写本地硬盘，无需担心本地存储介质问题.
-
SSHD服务启动失败 一台在线才5天的服务器，用 lastb |wc -l 统计了下，有近十万次的暴力破解登录失败记录。隧想改下 sshd 的监听端口，免得招蜂引蝶。打开配置文件 /etc/ssh/sshd_config 把默认的22端口改成高位端口后，用 systemctl restart sshd.service 重启sshd服务失败。报错如下：Job for sshd.service failed because the control process exited with error code. See "systemctl status sshd.service" and "journalctl -xe" for details.systemctl status sshd.service 的输出如下：● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since 四 2018-09-27 10:10:42 CST; 38s ago Docs: man:sshd(8) man:sshd_config(5) Process: 47324 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=255) Main PID: 47324 (code=exited, status=255) 9月 27 10:10:42 english systemd[1]: sshd.service: main process exited, code=exited, status=255/n/a 9月 27 10:10:42 english systemd[1]: Failed to start OpenSSH server daemon. 9月 27 10:10:42 english systemd[1]: Unit sshd.service entered failed state. 9月 27 10:10:42 english systemd[1]: sshd.service failed.没啥有用的提示，再看 journalctl -xe-- Unit sshd.service has begun starting up. 9月 27 10:12:07 english sshd[47352]: error: Bind to port 23389 on 0.0.0.0 failed: Permission denied. 9月 27 10:12:07 english sshd[47352]: error: Bind to port 23389 on :: failed: Permission denied. 9月 27 10:12:07 english sshd[47352]: fatal: Cannot bind any address. 9月 27 10:12:07 english systemd[1]: sshd.service: main process exited, code=exited, status=255/n/a 9月 27 10:12:07 english systemd[1]: Failed to start OpenSSH server daemon. -- Subject: Unit sshd.service has failed -- Defined-By: systemd说我没权限绑定 23389 端口，老夫是 root 咋会没权限呢？/var/log/messages 里面没有啥有用的提示， /var/log/secure 里面的提示跟上面显示一样，没权限。两头雾水。经验告诉我，当日志里面没明显提示，而服务又是和安全相关的时候，锅往 selinux 上甩准没错，果然 getenforce 返回的是 Enforcing 。执行 setenforce 0 关闭 selinux 后，一切正常。最后提醒下，修改 sshd 配置文件属于高危操作，要慎之又慎，如上文，端口改成23389后，你重启sshd服务让修改生效，重启这个动作分解是这样的：1、停止SSHD服务2、用修改后的新配置文件启动SSHD服务，而此时配置文件有误，无法启动SSHD。无法启动SSHD服务，这想想都刺激呢？若是云服务器还好，可以通过web控制台的console连接上去操作，若是托管在IDC机房的机器，只能去机房接显示器了。比较安全的方法就是用一个脚本每隔20分钟把正确的sshd配置文件覆盖回来，然后启动SSHD服务，当你确认修改成功后，再取消掉这个脚本。
-
Linux宝塔面板解决php-fpm占用CPU过高全记录 宝塔面板实际上也很实用，但是随着我认真做站的程度，突然发现网站越来越卡，基本上达到无法使用的状态，无法访问（502）的时间甚至达到了几个小时。这种情况严重干扰了我的做站热情和我的用户们的心情，这让我不得不去寻找究竟是什么原因。开始的时候我怀疑因为我设置的弱密码导致被攻击了，或者系统以及“被挖矿”了，对于我这种半吊子的个人站长来说在日志里真的也查不到什么有用的信息。于是乎祭出大杀器：重装系统。重装系统这个杀器我是跟我大学室友学的，反正他每次电脑遇到什么情况都是装系统。哈哈哈哈，继续说回来。昨天真是装系统、装环境、转移网站各种眼花缭乱的操作之后还是解决不了什么问题。后来又怀疑是mysql版本的问题，初始我装的mysql版本是5.5的，top命令发现mysql占用内存过大，于是就换到5.1。来来回回装了大概有6次，还是解决不了问题。简直无奈了，一度怀疑是服务器配置太低都准备入手高配了，但是还是不死心。今天早上突然又开始502了，top命令盯着一早上，突然发现php-fpm占用内存奇高无比。有门，也许杀死这个进程就能够解决问题了。搜索一通发现果真是php-fpm的问题。记录一下解决过程，希望下次遇到同类问题就不会束手无策了。解决方案1、通过宝塔面板安装的建站环境是LNMP，使用的Nginx 1.16.1、MySQL 5.5.62、PHP-7.0。2、优化PHP7.0设置。按下图操作先进入到PHP7.0管理页面。首先先安装一个opcache缓冲器，用于加速PHP脚本，其他的就都按默认的来吧，毕竟安装的扩展太多容易影响性能。修改max_execution_time时间为20.性能调整。这里大家可以根据自己服务器配置进行设置，宝塔面板比较人性化，会根据你的服务器配置设置推荐方案。其实设置并发多少，大家可以根据自己服务器内存大小进行计算，一般一个php-fpm进程占用内存30M左右，以1024MB内存（1G内存）来计算，大概可以设置34个并发。我使用的就是1核1G内存配置的服务器，安装宝塔面板后推荐的是40并发，但我觉得自己根本用不到那么高的并发，所以设置了20并发的方案，并把max_spare_servers数字调整成了14.我按照上面操作后，发现服务器CPU不像之前一样经常性占用100%了，虽然php-fpm有时候还会出现突发占用CPU 100%的情况，但基本很快就会恢复正常，对用户的浏览不会造成过多的影响。分析原因的话不知道是不是兼容性问题，因为我个人对这些东西没有过多的研究，只是恰巧碰到运气而已吧，说得不对的地方请大佬们指正。-END-
