Hi The problem seems to be fixed in 2.6.32-358.18.1.el6.centos.plus.x86_64
Finally found how to install it properly on Debian 7. Here is results: # hdparm -t /dev/mapper/vg-root /dev/mapper/vg-root: Timing buffered disk reads: 992 MB in 3.00 seconds = 330.13 MB/sec Much better as you can see. How long it would take to get that fix into OpenVZ kernel? Bug link: http://bugs.centos.org/view.php?id=6548 Kernel: http://ftp.tu-chemnitz.de/pub/linux/centos/6.4/centosplus/x86_64/Packages/kernel-2.6.32-358.18.1.el6.centos.plus.x86_64.rpm 2013/8/29 spameden <[email protected]> > > > > 2013/8/29 Kirill Korotaev <[email protected]> > >> SSDSC2CW240A3 == Intel 520. It's not server grade as well and though it >> behaves much much better then desktop SSDs - we still saw it's loosing >> commits on power failure. So beware that your database can corrupt or loose >> transactions. >> All server grade SSDs from Intel have "Enhanced power-loss data >> protection" feature in specs which implies capacitors on the board for >> saving data to NVRAM. It's 320, 710 and S3700 models. >> Intel S3700 is the best and fastest we ever saw among different models >> including non-Intel ones and this is what Parallels recommends in Parallels >> Cloud Storage. >> > > Ofc it's not that good, but we can't offer right now to buy overpriced > hardware (for us, at least). > > Our database is XtraDB and it's commiting every second. > > Losing 1 second of transactions is not a problem for us. > > However, slow speed with 2.6.32 openvz kernel is a problem. As you can see > there is a problem on this particular kernel. > > I'll try to investigate more and report back. > >> >> >> >> On Aug 29, 2013, at 13:20 , spameden <[email protected]> >> wrote: >> >> >> >> >> 2013/8/29 Kirill Korotaev <[email protected]> >> >>> I also want to add that SSD models referred to in the bug (like OCZ >>> one) are not server grade and you guys risk very much loosing your data or >>> corrupting file system on power failure. >>> You should test it heavily. >>> >> >> Thanks for that. >> >> But we are not using OCZ (also know they are not reliable). >> >> The SSD in this server is INTEL SSDSC2CW240A3. >> >> I can't try the latest redhat kernel on this system, because after >> converting it to deb it seems to be not working. >> >> But I believe fix should be in 2.6.32-358.18.1.el6.centos.plus.x86_64. >> >>> >>> On Aug 29, 2013, at 03:52 , Kir Kolyshkin <[email protected]> wrote: >>> >>> On 08/28/2013 06:34 AM, spameden wrote: >>> >>> >>> >>> >>> 2013/8/28 Kir Kolyshkin <[email protected]> >>> >>>> On 08/27/2013 08:20 AM, spameden wrote: >>>> >>>> ArchLinux wiki says: >>>> *Warning: *Users need to be certain that kernel version 2.6.33 or >>>> above is being used AND that their SSD supports TRIM before attempting to >>>> mount a partition with the discard flag. Data loss can occur otherwise! >>>> >>>> So I guess it's not in the OpenVZ kernel? >>>> >>>> I'd like to use TRIM because it increases performance to SSD >>>> drastically! >>>> >>>> >>>> You'd better check it with Red Hat, looking into their RHEL6 >>>> documentation. >>>> >>>> My quick googling for "rhel6 kernel ssd discard" shows that rhel6 kernel >>>> do support trim, they have backported it (as well as tons of other >>>> stuff, >>>> so this is hardly 2.6.32 kernel anymore). >>>> >>> >>> I've just tested via hdparm (ofc it's not a perfect tool to test out >>> disk performance but still), here is what I get on the latest >>> 2.6.32-042stab079.5: >>> >>> # hdparm -t /dev/mapper/vg-root >>> /dev/mapper/vg-root: >>> Timing buffered disk reads: 828 MB in 3.00 seconds = 275.56 MB/sec >>> >>> on standard debian-7 kernel (3.2.0-4-amd64): >>> # hdparm -t /dev/mapper/vg-root >>> /dev/mapper/vg-root: >>> Timing buffered disk reads: 1144 MB in 3.00 seconds = 381.15 MB/sec >>> >>> and it's only read speed test. >>> >>> I don't get why it differs so much? >>> >>> >>> My suggestion is, since this functionality is not directly related to >>> OpenVZ, and >>> we usually don't change anything in this code (unless there is a reason >>> to), to >>> try reproducing it on a stock RHEL6 kernel and, if it is reproducible, >>> file a bug >>> to red hat or, if it's not reproducible, file a bug to openvz. >>> >>> Kir. >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> https://lists.openvz.org/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> https://lists.openvz.org/mailman/listinfo/users >>> >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> https://lists.openvz.org/mailman/listinfo/users >> >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> https://lists.openvz.org/mailman/listinfo/users >> >> >
_______________________________________________ Users mailing list [email protected] https://lists.openvz.org/mailman/listinfo/users
