Greetings: Based on some of the discussion so far in this thread (which thank you all by the way for your input!) has led me down some holes I was afraid to go down (building from source). I'm not averse to it for technical reasons, just.. its a time consumer. :) In any case I did run some tests on the box, building MySQL from source with a variety of -mtune attempts (niagara, niagara2/3, etc), and interestingly enough all of those attempts yielded a system that actually was _slower_ than the 'stock' binaries distributed with Debian SPARC (Wheezy).
I am currently attempting a MariaDB build on the machine, but have been running into some compile-time errors (I'm not very experienced in porting to different architectures), as I was unable to find any binaries of MariaDB (hoping its claims of faster/better would apply here). I'll drop a reply if I ever get Maria built and see a difference. Thanks again for all the input, much appreciated! Regards, Chris On Tue, Jan 28, 2014 at 4:19 AM, Rainer Herbst <[email protected]> wrote: > Single thread performance of the T2000 is definatly lower than of x86 > hardware, but a factor of 30 is to high. I would have expected factor 3-4, > maybe 10. > > We use a T2000 for LDAP and MySQL server in Solaris 10 LDOMs, and the system > perform reasonably well. > > > > Mit freundlichen Grüßen, > > Rainer Herbst > Zentrale Einrichtung für Informations- > verarbeitung und Kommunikation (ZEIK) > Universität Potsdam > Am Neuen Palais 10, Haus 8, Zimmer 0.70a > 14469 Potsdam > Tel. 0331 - 977 1039 > > > Quoting Patrick Baggett <[email protected]>: > >> Just from reading others' questions and answers over the web, I wouldn't >> be >> surprised if that was the case, especially if you are doing anything that >> needs an FPU in there. Also IIRC, they are in-order CPUs, which means >> having proper compiler flags will make a difference. Stock MySQL from >> Debian probably doesn't have any special flags applied, whereas you'd >> probably want "-mtune=niagara". >> >> I'm interested in finding out the answer as well -- I've considering >> picking up a used T2-based, which has similar characteristics, since they >> are down to a few hundred dollars. >> >> Patrick >> >> >> >> >> On Mon, Jan 27, 2014 at 1:35 PM, Chris Lawrence <[email protected]> wrote: >> >>> Greetings: >>> >>> I have been gifted a Sun T2000 from my employer as a hand-me-down >>> piece of hardware. I have had plenty of experience using it as a >>> Solaris 10 box, and we generally ran Oracle and our in-house products >>> on the hardware with good results. >>> >>> After getting the hardware, without a Sun contract I went with Debian, >>> which was fine as my expertise/background is more heavily Linux than >>> Solaris anyways. >>> >>> After a lot of tinkering I got the system as I liked it, prepared to >>> host several LXC containers, separated as database and web servers for >>> a project for my friend's gaming website. All went well, until I >>> started working with MySQL. I started noticing significant >>> differences in performance, and, I went down the rabbit hole to find >>> plenty of articles talking about how MySQL doesn't run well on The >>> T2000's due to single threadedness sort of reasons. >>> >>> I've done a good amount of fine tuning of the database, but I'm >>> finding any query of complexity taking sometimes as much as 30x longer >>> to execute than on same-era x86 hardware running Debian. >>> >>> I am really just trying to figure out if I'm wasting my time by trying >>> to 'fix' this, or if its a reality of the hardware platform. Even >>> simple 'select BENCHMARK' queries are returning back after 25-30 >>> seconds, whereas on the x86 box it comes back in 1-2 seconds. >>> >>> Is MySQL on this hardware platform a lost cause, or am I missing >>> something obvious? >>> >>> Thanks in advance! >>> >>> Regards, >>> >>> Chris >>> >>> >>> -- >>> To UNSUBSCRIBE, email to [email protected] >>> with a subject of "unsubscribe". Trouble? Contact >>> [email protected] >>> Archive: >>> >>> http://lists.debian.org/caouezgjvmyjpmpowtpjvafmpy0uneext3pctwxypanapdlv...@mail.gmail.com >>> >>> >> > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/caouezgkkvfeo_6wocjhmtwt0nots3hhq-bpjkdzmvfmvqtg...@mail.gmail.com
