V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Recommended Services
Amazon Web Services
LeanCloud
New Relic
ClearDB
zjxubinbin
V2EX  ›  云计算

阿里云真渣

  •  2
     
  •   zjxubinbin · 2016 年 2 月 26 日 · 7436 次点击
    这是一个创建于 3612 天前的主题,其中的信息可能已经有所发展或是发生改变。
    1CPU 1G 内存的机器编译个 MySQL5.7 竟然无响应了,Putty 连不上,官网的管理终端好歹可以登入,但是响应超级慢
    50 条回复    2016-02-29 17:19:00 +08:00
    xshell
        1
    xshell  
       2016 年 2 月 26 日
    配置太差。
    zjxubinbin
        2
    zjxubinbin  
    OP
       2016 年 2 月 26 日
    @xshell 我本地的奔腾 G3260 开的 512M 的 VMWare 都流畅编译了
    zjxubinbin
        3
    zjxubinbin  
    OP
       2016 年 2 月 26 日
    @xshell 而且腾讯云上面两台 1 核 1G 的也都流畅编译
    est
        4
    est  
       2016 年 2 月 26 日
    LZ 你去买一个 1CPU 1G 内存的机器编译 MySQL 会一样得出机器很渣的结论。
    xshell
        5
    xshell  
       2016 年 2 月 26 日
    阿里的 IO 性能差是出了名的, XX 云没法和物理机比,而且都是共享 cpu 内存等等,超售·
    GhostEX
        6
    GhostEX  
       2016 年 2 月 26 日
    同样感受,甚至连环境都运行不好。腾讯云香港服务器怎么样?
    Andy1999
        7
    Andy1999  
       2016 年 2 月 26 日 via iPhone
    开 Swap
    腾讯编译 5.7 Swap 都吃了 1.6G
    不过还是改变不了阿里云是垃圾这个事实
    Andy1999
        8
    Andy1999  
       2016 年 2 月 26 日 via iPhone
    @GhostEX 我买的时候是全球绕
    现在走日本 NTT
    如果大客户应该可以调整路由
    strahe
        9
    strahe  
       2016 年 2 月 26 日
    那些说配置差的根本没体会过普通老百姓的生活,我 1CPU , 512M 内存各种应用各种编译也没见啥事
    imydou
        10
    imydou  
       2016 年 2 月 26 日
    阿里云有个 windows 镜像 我忘了 是 2008 还是 2012
    开机以后 默认没开虚拟内存,很容易出错
    nooper
        11
    nooper  
       2016 年 2 月 26 日
    不不你应该配置 swap 。
    zeac
        12
    zeac  
       2016 年 2 月 26 日
    刚在阿里云上配置 Nginx ,要生成一个 dhparam.pem ,在 aliyun 上等了快 10 分钟都没搞定,顺手在本地 Virtualbox 分了 2 核的虚拟机下一分钟就生成了,一看吓我一跳,回去看了下阿里云还在运行,无语了

    本地是 2 核 128MB 内存,阿里云是 1G1 核

    我一直以为阿里云再配置再怎么差也总比我本地 E5500 会好,没想到相差这么大
    SlipStupig
        13
    SlipStupig  
       2016 年 2 月 26 日
    请不要模仿我的主题好不
    zjxubinbin
        14
    zjxubinbin  
    OP
       2016 年 2 月 26 日
    @zeac 我之前还把阿里云又续费了一年...现在看来只能呵呵呵了
    zjxubinbin
        15
    zjxubinbin  
    OP
       2016 年 2 月 26 日
    @SlipStupig 估计接下来会有越来越多的对阿里云的吐槽
    em70
        16
    em70  
       2016 年 2 月 26 日 via iPhone
    不要自己搭建 MySQL ,用 RDS 性能非常好
    tntsec
        17
    tntsec  
       2016 年 2 月 26 日
    不编译不就行了,把 mariadb 的源扔进去,直接装
    odirus
        18
    odirus  
       2016 年 2 月 26 日
    RDS+1 , DRDS+1
    nlzy
        19
    nlzy  
       2016 年 2 月 26 日 via Android
    从上次云盾删文件的事故发生之后我就没再用阿里云了

    PS:我本地 VMware 里的 FreeBSD 编译 MariaDB 10.0 用 2G 内存+1G swap 都会被 kill ,楼上 512M 怎么编译的,是我姿势不对么←_←
    JJaicmkmy
        20
    JJaicmkmy  
       2016 年 2 月 26 日 via iPhone
    @Andy1999 现在 A 区移动直联,电信联通绕道 NTT , B 区以前移动联通电信都直联,现在移动联通也要走电信 CN2 。
    SlipStupig
        21
    SlipStupig  
       2016 年 2 月 26 日
    @nlzy 对于用户的补偿更是搞笑,由于对用户造成的不便我们将免费送您一年阿里安全......
    ragnaroks
        22
    ragnaroks  
       2016 年 2 月 26 日
    阿里云除了 IO 和网络其他的还行
    aliyunservice
        23
    aliyunservice  
       2016 年 2 月 26 日
    您好,在 1G 的配置下编译 mysql 资源上还是比较紧张的,建议您开启 swap 再观察下,如果还有问题可以随时联系阿里云。
    macroideal
        24
    macroideal  
       2016 年 2 月 26 日
    是你钱没有给够吧
    rogeecn
        25
    rogeecn  
       2016 年 2 月 26 日
    这是让你买 RDS 的节奏。
    jarlyyn
        26
    jarlyyn  
       2016 年 2 月 26 日
    阿里云可能的确是挺渣。

    但是动不动编译一个数据库也是够了……
    strwei
        27
    strwei  
       2016 年 2 月 26 日
    超兽大法好
    linjuyx
        28
    linjuyx  
       2016 年 2 月 26 日
    开 swap
    linjuyx
        29
    linjuyx  
       2016 年 2 月 26 日
    但阿里云普通实列 io 确实垃圾
    chousb
        30
    chousb  
       2016 年 2 月 26 日
    企业用户的话可以试试青云 QingCloud
    lobee90
        31
    lobee90  
       2016 年 2 月 26 日
    2G 内存走起啊。 SWAP 开了也是很慢的,就算 SSD 也不及内存的速度的。
    这里楼主的问题,阿里云无端背锅
    不过,阿里云确实坑就是了。但不是楼主这种让阿里云背锅的坑法
    Neveroldmilk
        32
    Neveroldmilk  
       2016 年 2 月 26 日
    只是当代码管理仓库用,你还真敢把它当运算服务器么?
    zjxubinbin
        33
    zjxubinbin  
    OP
       2016 年 2 月 27 日
    @lobee90 我两台腾讯云,一台 Linode,一台 Vultr 都是 1 核 1G,差不多同时开始编译同一个版本的 MySQL,只有阿里云的无响应了~难道这个锅要我来背?
    dommyet
        34
    dommyet  
       2016 年 2 月 27 日 via Android
    @zeac 這個很看人品的即使是同配置每次生成所需時間是不同的 可能秒出 可能很久
    gzelvis
        35
    gzelvis  
       2016 年 2 月 27 日 via iPhone
    @JJaicmkmy 怪不得最近去阿里 B 比以前慢了那么多,广州联通
    est
        36
    est  
       2016 年 2 月 27 日   ❤️ 1
    @aliyunservice V2EX 第 160650 号会员,加入于 2016-02-26 11:41:45 +08:00 ,今日活跃度排名 2127

    你们爬虫很叼啊。随时都可以召唤到。
    hpeng
        37
    hpeng  
       2016 年 2 月 27 日 via iPhone
    我试过用搬瓦工的 128m 那款编译 ruby ,没炸,同时开着 htop 观察。下次试下 MySQL
    Abbey
        38
    Abbey  
       2016 年 2 月 27 日
    RDS + 1
    hongfeiyu
        39
    hongfeiyu  
       2016 年 2 月 27 日
    @est 6666666666 这是怎么做到的
    yjd
        40
    yjd  
       2016 年 2 月 27 日
    阿里云 IO 是非常差的。
    kozora
        41
    kozora  
       2016 年 2 月 27 日
    石头盘
    neoblackcap
        42
    neoblackcap  
       2016 年 2 月 27 日
    要编译的话,请开大内存实例,那么就会减少 swap 。阿里云上面你还想做 IO 密集型的操作,我只能说 LZ 你还真有想象力。
    用本地虚拟机对比阿里云根本不可比,你看看阿里云的 IOPS 就知道,跟你本地完全没办法比嘛。
    Outshine
        43
    Outshine  
       2016 年 2 月 27 日
    @est 哈哈,突然召唤失败了吧!
    hustlike
        44
    hustlike  
       2016 年 2 月 27 日
    其实我也是这个配置,主要就是用来跑一些外包项目,这个配置还折腾啥啊。。不过 ssh 速度还是很快的
    lzhd24
        45
    lzhd24  
       2016 年 2 月 27 日 via Android
    在渗透测试时发现,阿里云设置监听地址直接是公网 ip 比较方便,而腾讯云监听需要设成内网 ip ,稍稍麻烦
    shawnall
        46
    shawnall  
       2016 年 2 月 29 日   ❤️ 1
    @lzhd24 aliyun 的是 bridge 桥接,腾讯云的是 nat 转发方式,中间高防之类都可以做,所以腾讯云的基础高防会更直接有效一点
    chousb
        47
    chousb  
       2016 年 2 月 29 日
    @ragnaroks 除了 IO 和网络,云计算还剩下的真不多。。
    stevele
        48
    stevele  
       2016 年 2 月 29 日
    阿里的 IO 性能差是出了名的。。。。。。
    king110
        49
    king110  
       2016 年 2 月 29 日
    @SlipStupig 高级黑。。
    lzhd24
        50
    lzhd24  
       2016 年 2 月 29 日 via Android
    @shawnall 原来如此
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   1025 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 286ms · UTC 18:40 · PVG 02:40 · LAX 10:40 · JFK 13:40
    ♥ Do have faith in what you're doing.