您的位置:

mysql跨服务器慢,mysql特别慢

本文目录一览:

PHP连接远端mysql很慢,要5-10秒,修改了my.cnf配置文件还是没用

这个问题我遇到过,一般出现这种情况都是DNS反解析问题,还有SSH连接过慢问题也是。

搞定的方法,就是加入google的DNS:8.8.8.8

windows系统可以配置第备用DNS为8.8.8.8

Linux系统可以配置为nameserver 8.8.8.8

MySQL数据库服务器逐渐变慢分析与解决方法分享

一、检查系统的状态

通过操作系统的一些工具检查系统的状态,比如CPU、内存、交换、磁盘的利用率,根据经验或与系统正常时的状态相比对,有时系统表面上看起来看空闲,这也可能不是一个正常的状态,因为cpu可能正等待IO的完成。除此之外,还应观注那些占用系统资源(cpu、内存)的进程。

1.使用sar来检查操作系统是否存在IO问题

#sar-u210—

即每隔2秒检察一次,共执行20次。

结果示例:

注:在redhat下,%system就是所谓的%wio。

Linux2.4.21-20.ELsmp

(YY075)05/19/2005

10:36:07AMCPU%user%nice%system%idle

10:36:09AMall0.000.000.1399.87

10:36:11AMall0.000.000.00100.00

10:36:13AMall0.250.000.2599.49

10:36:15AMall0.130.000.1399.75

10:36:17AMall0.000.000.00100.00

其中:

%usr指的是用户进程使用的cpu资源的百分比;

%sys指的是系统资源使用cpu资源的百分比;

%wio指的是等待io完成的百分比,这是值得观注的一项;

%idle即空闲的百分比。

如果wio列的值很大,如在35%以上,说明系统的IO存在瓶颈,CPU花费了很大的时间去等待I/O的完成。Idle很小说明系统CPU很忙。像以上的示例,可以看到wio平均值为11,说明I/O没什么特别的问题,而idle值为零,说明cpu已经满负荷运行了。

2.使用vmstat监控内存

cpu资源

[root@mysql1

~]#

vmstat

procs

———–memory———-—swap–

—–io—-–system–

—–cpu——

r

b

swpd

free

buff

cache

si

so

bi

bo

in

cs

us

sy

id

wa

st

72

25428

54712672264

14

43

53

59

1

198

vmstat

的输出那些信息值得关注?

io

bo:

磁盘写的数据量稍大,如果是大文件的写,10M以内基本不用担心,如果是小文件写2M以内基本正常

CPU问题

下面几列需要被察看,以确定cpu是否有问题

Processesinthe

run

queue

(procs

r)

Usertime

(cpu

us)

System

time

(cpu

sy)

Idle

time

(cpu

id)

问题情况:

如果processes

in

run

queue

(procs

r)的数量远大于系统中cpu的数量,将会使系统便慢。

如果这个数量是cpu的4倍的话,说明系统正面临cpu能力短缺,这将使系统运行速度大幅度降低

如果cpu的idle时间经常为0的话,或者系统占用时间(cpu

sy)是用户占用时间(cpu

us)两辈的话,系统面临缺少cpu资源

解决方案

:

解决这些情况,涉及到调整应用程序,使其能更有效的使用cpu,同时增加cpu的能力或数量

②内存问题

主要查看页导入的数值(swap中的si),如果该值比较大就要考虑内存,大概方法如下:

最简单的,加大RAM

减少RAM的需求

3.磁盘IO问题

处理方式:做raid10提高性能

4.网络问题

telnet一下MySQL对外开放的端口,如果不通的话,看看防火墙是否正确设置了。另外,看看MySQL是不是开启了skip-networking的选项,如果开启请关闭。

访问外网的mysql数据库比较慢是怎么解决

服务器放在局域网内进行测试时,数据库的访问速度还是很快。但当服务器放到外网后,数据库的访问速度就变得非常慢。

后来在网上发现解决方法,my.ini里面添加

[mysqld]

skip-name-resolve

这样速度就快了!

skip-name-resolve

选项就能禁用DNS解析,连接速度会快很多。不过,这样的话就不能在MySQL的授权表中使用主机名了而只能用ip格式。

就MySQL本身而言,问题出在在mysql dns反解析

mysqlshow processlist;

| 20681949 | unauthenticated user | 10.10.4.193:52497 | NULL | Connect | | Reading from net | NULL |

| 20681948 | unauthenticated user | 10.10.4.193:52495 | NULL | Connect | | Reading from net | NULL

发现有非常多的 unauthenticated user 尝试做登入使用 mysql 的情况 ,当这种情况无限制发生时就会造成系统十分缓慢。

查阅mysql官方网站得知,这属于官方一个系统上的特殊设定,就把他当成mysql的一个bug算了,不管链接的的方式是经过 hosts 或是 IP 的模式,他都会对 DNS 做反查。mysqld 会尝试去反查 IP - dns ,由于反查解析过慢,就会无法应付过量的查询。

MYSQL跨服务器跨库关联表查询很慢怎么解决

CSDN官方APP

中国专业的IT社区立即下载

CSDN首页

博客

学院

下载

GitChat

论坛

APP

问答

商城

VIP

活动

招聘

ITeye

TinyMind

专题

Copyright © 1999-2019,

CSDN.NET, All Rights Reserved

crimeheaven的专栏

登录

crimeheaven关注 访问量 6万+ 原创 22 博主更多文章

转 mysql跨库操作速度慢的解决方案

crimeheaven阅读数:24752014-03-14

远程连接mysql速度慢的解决方法:skip-name-resolve取消DNS的反向解析

PHP远程连接MYSQL速度慢,有时远程连接到MYSQL用时4-20秒不等,本地连接MYSQL正常,出现这种问题的主要原因是,默认安装的MYSQL开启了DNS的反向解析,在MY.INI(WINDOWS系统下)或MY.CNF(UNIX或LINUX系统下)文件的[mysqld]下加入skip-name-resolve这一句。

但是,这样会引起一个问题:连接mysql时,不能使用 localhost连接了,而是要使用IP地址的;如果是按localhost对用户赋权限的话,用户登录权限也要修改一下的。

连接mysql速度慢的解决方法. 

2台服务器,一台跑iis+php,一台跑mysql,和以往一样配置好环境,测试页面一切OK

跑应用的时候发现php访问mysql速度很慢,这种情况在以前从未发现过,虽然2台服务器并非在同一网段中,但是ping数值基本上都在1,2ms之间,tcp连接应该不是问题关健,google以后找到答案,在my.ini文件的[mysqld]部分加入:skip-name-resolve,保存文件,重启mysql,一切OK啦,速度象飞一样了

新版本的mysql配置起来不象以前的那个傻瓜化了,这个问题折腾了我一上午的时间,晚上回来总算是解决了,嘿嘿,又学到一些东西。 

Windows 2003下的MySQL 5服务器,本机连接到MySQL服务非常快,局域网内有两台Linux机器,有一台连接很快,另外一台输入密码后要等好几秒钟才能连上。

MySQL数据库服务器逐渐变慢 该如何分析与解决

MySQL 在崩溃恢复时,会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性,如果 MySQL 中包含了大量表,这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关,表总数越大,崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间,像这里开发库的 HDD IOPS 较低,因此面对大量的表空间,校验速度就非常缓慢。另外一个发现,MySQL 8 下正常启用时居然也会进行表空间校验,而故障恢复时则会额外再进行一次表空间校验,等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性,即表数量超过 5W 时,会启用多线程扫描,加快表空间校验过程。

如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛?查阅了资料,方法主要有两种:

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ,那么 validate = false,即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1,也就是强制恢复跳过坏页,就可以跳过校验,然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程,快速启动 MySQL,个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了,只需要打开一个 ibdata 文件即可,大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后,感觉共享表空间在很多业务环境下,反而更有优势。

临时冒出另外一种解决想法,即用 GDB 调试崩溃恢复,通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程,然后让 MySQL 正常关闭,重新启动就可以正常启动了。但是实际测试发现,如果以 debug 模式运行,确实可以临时修改 validate 变量,跳过表空间验证过程,但是 debug 模式下代码运行效率大打折扣,反而耗时更长。而以非 debug 模式运行,则无法修改 validate 变量,想法破灭。