EVE Search - Enough with the "Server is Down" threads

All Channels

EVE General Discussion

Enough with the "Server is Down" threads

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 [2] :: one page
Author	Thread Statistics \| Show CCP posts - 2 post(s)
Eventy One	Posted - 2007.09.12 20:04:00 - [31] Originally by: Jimer Lins I find it extremely difficult to take anyone who uses terms like "M$SQL" seriously. If you want to have an adult conversation, try to avoid using such childish terms; any point you may have had is immediately lost because people see that and you're instantly pigeonholed as not someone with an idea, but with an axe to grind, and they stop paying attention to anything you say. Man u 31337! Cheers Eventy One (PS anyone think I scared the troll away? Good thing he didn't read past the M$SQL - he might have hung around!)
Jimer Lins Gallente Sanctuary	Posted - 2007.09.12 20:10:00 - [32] Originally by: Eventy One Man u 31337! Cheers Eventy One (PS anyone think I scared the troll away? Good thing he didn't read past the M$SQL - he might have hung around!) Ladies and gentlemen, I rest my case. And if responding in a civil fashion is trolling, guilty as charged. Of course, your response only proves exactly my first point. SEARCh- we find sites for you!
Kwint Sommer Incoherent Inc Otaku Invasion	Posted - 2007.09.12 20:13:00 - [33] Originally by: Eventy One 2. Post some other true, but more useful observation such as - If CCP has used MySQL (and linux) instead of M$SQL (and Windows) - this likely would not be happening every time a patch is applied Get your facts straight, the server crashed repeatedly in the hours before the patch was applied so the patch is most likely not the reason. Further, if you haven't built a database of this size from the ground up -only a few dozen people in the world have- then stop *****ing about the language and platform they used to do it. They used what they thought was best and you're not in a position to second guess them so stop pretending to know better than its creators. I don't care how much more 1337 you think Linux is, that doesn't make it the best platform for all projects. By the way, I and many others make attempts at witty banter in those "server is down threads" so it doesn't all need to be done away with.
Grawshellar	Posted - 2007.09.12 20:16:00 - [34] There's no "serious" discussion of this type anyways. On these forums: 50% of the people mysteriously are game developers 25% manage clusters that make the eve server blush 10% have been programming since the Amiga 10% are celebrities/bill gates/Linus Torvald
Winterblink Body Count Inc. Mercenary Coalition	Posted - 2007.09.12 20:17:00 - [35] Originally by: Eventy One You say correctly "argue that until you're blue in the face". The argument will come down to the those that say MySQL has no support, and those that point to MySQL.com as evidence to the contrary. I'm definitely in the latter camp knowing that MySQL makes it money not on the DB but on their service, but I also realize perception is everything. Perception IS everything, and to most clients I've dealt with, if you mention MySQL to them a small question mark pops out of their ear and floats up into the air. The argument doesn't just boil down to the mere existence of support, but the perception of how high quality that might be. For most organizations, Microsoft and Oracle are known quantities, thus a safer bet for high risk initiatives. In addition, 99% of the time they fall in-line with existing licensing that may already be in place. warp drive active \| nature vraie
Turix Interstellar eXodus R0ADKILL	Posted - 2007.09.12 20:38:00 - [36] Valid point there winter, the problem i've run into with Microsoft (No experiance of Oracle), while the support is there its often not good quality support, its the same with the entire microsoft range really though. If you pose a question which the techies might have to actually think about they either wont respond, they'll forward you around in circles between each other or just give you some vauge answer than is no use to anyone and close the topic. Might be some bad experiances on my part i dunno, but as far as support goes i stick to the theory that public support > the companies own support. Iv found much more support for most programs from alot of companies on fan made wiki's and forums than the website of the company that made them or the manual/documentation that comes with. \| Image Hosting \| My Movies \|
Mallick Northern Intelligence Veritas Immortalis	Posted - 2007.09.12 20:54:00 - [37] Oracle, enough said!
Sainna Minmatar Brotherhood of the Void	Posted - 2007.09.12 21:10:00 - [38] Edited by: Sainna on 12/09/2007 21:10:53 Originally by: Grawshellar There's no "serious" discussion of this type anyways. On these forums: 50% of the people mysteriously are game developers 25% manage clusters that make the eve server blush 10% have been programming since the Amiga 10% are celebrities/bill gates/Linus Torvald Just a small change: 49% of the people mysteriously are game developers 25% manage clusters that make the eve server blush 10% have been programming since the Amiga 10% are celebrities/bill gates/Linus Torvald 01% worry to much about other's personal qualifications Drill Instructor: "If your nature didn't lead you to trample everyone in your path with vindictive glee, you might be tolerable.
James Lyrus Lyrus Associates Betrayal Under Mayhem	Posted - 2007.09.12 21:34:00 - [39] Originally by: XiticiX Much MUCH faster. It's probably still an issue though. I/O can only move so fast. It's a problem that encompasses the entire infrastructure - Disk I/O, the latency of the network between servers, the latency of the database, as well as the latency of the internet to your home all play a part in this. The crashes are different though - this is most likely due to either corrupt data, locks on the database, or just plain bad coding practices which don't fail gracefully. Major limiting factor in I/O throughput when talking to a RAMSAN though is liable to be the number of HBAs (host bus adaptors - SCSI adaptors). With decent multipathing software, you can scale them _fairly_ linearly, and each can run at 4Gb/sec without too much difficulty. A quick look at the RAMSAN website suggests that they can run up to 8x8 4Gb interfaces. But looking a it, that's 8 per solid state disk. So you'd need to be having a rack full, and then essentially stripe across the whole lot to get that kind of throughput. Of course, at that point you start realising there's only _so_ many HBAs you can fit in your server, and down your PCI bus. IIRC most PCI slots 'share' buses, (even the new and shiny forms of PCI) which means that starts to become a bottleneck too. I've no idea if this is still the case, but it _used_ to be the major reason why people used UNIX systems over WINtel - you could just get more IO through a highend SUN server, which had knock on implications for high end databases. The fact that Oracle can use raw devices for io too (I don't _think_ MS SQL can, but I don't know) just put the icing on it. 'scuse me. I do storage for a living, and I just get .... enthusisastic over ninja spec systems. Crane needs more grid
Eventy One	Posted - 2007.09.13 04:25:00 - [40] Originally by: James Lyrus I've no idea if this is still the case, but it _used_ to be the major reason why people used UNIX systems over WINtel - you could just get more IO through a highend SUN server, which had knock on implications for high end databases. The fact that Oracle can use raw devices for io too (I don't _think_ MS SQL can, but I don't know) just put the icing on it. 'scuse me. I do storage for a living, and I just get .... enthusisastic over ninja spec systems. I'm not so sure any more with Sun running Intel architecture underneath. Many who purchase Sun don't even run Solaris any more (not saying that's a bad thing one way or the other) because they can run Linux with Intel. A Sun box just isn't a Sun any more. As for M$SQL (used the dollar sign because I know Jimer Lins _loves_ it) scaling, I have my doubts, but I know Oracle has a good reputation in the enterprise world for a reason (especially on a *nix). Cheers Eventy One
Gentle Glide Naughty 40 Triumvirate.	Posted - 2007.09.13 04:33:00 - [41] Epic Lose. ------------------------------------------- Originally by: CCP t20 So Let us play and enjoy the game you and I both love on the same level.
Grawshellar	Posted - 2007.09.13 04:40:00 - [42] Originally by: Sainna Just a small change: 49% of the people mysteriously are game developers 25% manage clusters that make the eve server blush 10% have been programming since the Amiga 10% are celebrities/bill gates/Linus Torvald 01% worry to much about other's personal qualifications Fair enough, I've just always been amazed at the number of claims in some other threads. I get a chuckle out of every "You should make this change, and I should know, I'm a game developers too" in features and Ideas. Also in other threads theres always a lot of "You should use XXXX language/DBMS/whatever because I've been in the field for years and blah blah". This is probably the first level headed thread along these lines that I've seen that wasn't full of "omg I r teh haX0r, use linux ccp n00bs" :P
lieut uhura	Posted - 2007.09.13 06:33:00 - [43] I think there are two issues to look at choosing database software. One: What is the performance, scalability & stability. Two: What is the level of support. The second issue here is forgotten most of the time by private users. (home users) I use mysql at home for my own cms. But for work i would not want it. (databases to complex) The company that i work for, uses two "brands" of database software. (we use databases for PDM & PLM) For the smaller databases, (read: database with <100 clients) we use Microsoft SQL. For the larger databases, (read: >100 clients) we use Oracle. Working with both, i must come to the conclusion that in large database environments i prefer Oracle. It is more stable, the level of support from Oracle is beter than that of Microsoft, and it preforms beter. The downsides of using Oracle: Requires more "tweaking" over time, Administrators need to have more expertise than with using Microsoft products. One of our "bigger" database environments that we have build and maintain, has more than 50.000 users and is replicated over 4 locations all over the globe. We rarely (read one time in over one year) have had downtime because the database crashed. Its not a matter of just comparing database software on sheer performance or personal preference, every database software has its positive & negative sides.
Nathalie Nebula Minmatar Nebula Enterpsies Crystal Planet	Posted - 2007.09.13 06:46:00 - [44] Originally by: CCP Wrangler Reopened. Very sad tbh. Those 'use X instead of Y because of some non-argument' should be closed, and podkilled for about a 100 times. -- Crystal Planet is recruiting
Born Slave Minmatar Pisces Formidilosi	Posted - 2007.09.13 06:50:00 - [45] Originally by: Nathalie Nebula Originally by: CCP Wrangler Reopened. Very sad tbh. Those 'use X instead of Y because of some non-argument' should be closed, and podkilled for about a 100 times. You are afraid of any form of discussion?
Kieran Jarnush	Posted - 2007.09.13 07:26:00 - [46] well it just shows how angry the players are. altho there's not more the lack of information the sorry here and there is just laughable. if they don't fix it soon there's no need for rev 3 .
Nolana Kane	Posted - 2007.09.13 07:32:00 - [47] Quoted from different thread to a similar topic: Quote: Quote: Originally by: Banana TorresIf you meant to say uninstall MS SQL Server and use MySql on Linux then that would be a debate worth having. But you didn't. Although he didn't formulate it right he surely had a point. Seriously, Mysql can't compete in this space. High availability, high load, lots of small, fast transactions: This market is divided between IBM, Oracle and Microsoft. I'd never dream to use Mysql for this. I just wonder why they are using a relational database at all. Sure it's quite convenient if you can use SQL to extract your data, but databases have problems with applications that have a high write rate. EVE is such an application. I think they would be better off using a memory-based database with a low priority thread which creates savepoints on disk. http://www.prevayler.org/wiki/ may be an example. In any case, they seriously would be better off using Oracle, which is a lot more mature than MS-SQL and used in most mission critical systems. MS-SQL is run by quite a few of our customers, but it is also generating the most trouble tickets.
FireFoxx80 Caldari E X O D U S Imperial Republic Of the North	Posted - 2007.09.13 07:38:00 - [48] I've said it before, and I'll say it again.... CCP chose MSSQL. Deal with it. If you really want CCP to start using mySQL, either: - STFU and leave Eve, if enough people do, then perhaps CCP will listen to the masses. - Expect 18 months of extended downtimes, no patches, and no bugfixes; whilst CCP manically try to change their database infrastrucutre. - Your subscription cost to increase, to pay for all the mySQL developers. That is all. What I do the rest of the time - Vote for a Jita bypass!
Faridah Solar Storm Sev3rance	Posted - 2007.09.13 07:55:00 - [49] CCP is saying it's a DB problem. Which probably seems true since it's the DB who fall over and die, causing all the nodes to fall apart as they can't read/write to the DB. However, it seems this problem started at a certain date and after that date the servers haven't been up 23 hrs. Unless they did some major changes in the DB I would think it could also be a external issue. Everyone with a little knowledge of relation DBs know that a misscoded INNER JOIN could wreck havoc on any DB, including mySQL, posgres, Oracle and M$SQL. The DB will do the select, but it locks down several tables and could use minutes to process. Things like this wouldn't be detected in Sisi as you might get a spike of lag, but it then finish and continue. On TQ this is fatal as the DB query-queues on some of the nodes fill up very fast, we get traffic advisories because of the load on that node, and things go south. This is a shot in the dark, but I would have dumped the query currently executing on the node to disk or something when it goes into 'traffic advisory mode'. This might reveal which tables are locked in the DB. This wouldn't affect performance at all because the code would not be executed unless that node is in deep **** already. It also wouldn't be lost as it writes the info to a place outside the DB (which is already toast) My point is.. Changing to a different DB might not be the solution.
Hyperforce99 Gallente Slacker Industries Exuro Mortis	Posted - 2007.09.13 08:23:00 - [50] Originally by: Faridah CCP is saying it's a DB problem. Which probably seems true since it's the DB who fall over and die, causing all the nodes to fall apart as they can't read/write to the DB. However, it seems this problem started at a certain date and after that date the servers haven't been up 23 hrs. Unless they did some major changes in the DB I would think it could also be a external issue. Everyone with a little knowledge of relation DBs know that a misscoded INNER JOIN could wreck havoc on any DB, including mySQL, posgres, Oracle and M$SQL. The DB will do the select, but it locks down several tables and could use minutes to process. Things like this wouldn't be detected in Sisi as you might get a spike of lag, but it then finish and continue. On TQ this is fatal as the DB query-queues on some of the nodes fill up very fast, we get traffic advisories because of the load on that node, and things go south. This is a shot in the dark, but I would have dumped the query currently executing on the node to disk or something when it goes into 'traffic advisory mode'. This might reveal which tables are locked in the DB. This wouldn't affect performance at all because the code would not be executed unless that node is in deep **** already. It also wouldn't be lost as it writes the info to a place outside the DB (which is already toast) My point is.. Changing to a different DB might not be the solution. which is probably whats happeneing, then again, what do we know about the exact things that go on in the server (except that it runs on specially trained hamsters)
Grez Minmatar Sybrite Inc.	Posted - 2007.09.13 09:13:00 - [51] MySQL doesn't scale as well as M$SQL, which I imagine was quite a huge deciding factor for CCP when they decided to go with M$SQL. Not to mention support. With MySQL, you're on your own - YOU need to fix the problems, and you don't have a support team to help you with your queries and such running on their software. The most they will do is tell you if your MySQL install is running fine, then point the finger at your queries. M$SQL, on the other hand, has paid support staff, which will help you with fine tuning your software. Since you purchased it, they're nice enough to offer their support in finding queries that would crash the software. This is much the same as Oracle. But you're paying a lot more for Oracle, and I'd imagine most people in CCP are much more in the know-how about SQL, than writing Oracle DB queries. Moving over to Oracle, might have been a great choice years ago when TQ first opened it's doors, but making a mass-move over to Oracle on the database could in fact, see performance drop. ---
Nolana Kane	Posted - 2007.09.13 09:21:00 - [52] Originally by: FireFoxx80 CCP chose MSSQL. Deal with it. Well, what I have to deal with is downtime I don't pay CCP for! Originally by: FireFoxx80 - Expect 18 months of extended downtimes, no patches, and no bugfixes; whilst CCP manically try to change their database infrastrucutre. That is why I hope they have a proper persistence layer up and running which generates the SQL statements for them. Switching to a different DB may be much cheaper and faster then. Of course, you have certain optimizations in place for different databases, but hopefully not thousands of them splattered around your code. Modern software architectures try to abstract away a lot of database-specific details. (Imagine: We're in the 21th and STILL have no single, valid SQL dialect for all DBs) Originally by: FireFoxx80 - Your subscription cost to increase, to pay for all the mySQL developers. Well, that is just stupid. You can buy premium support for mySQL and it may well be that this will be cheaper than MS-Support. Still I think MySQL won't be up for the task at hand. What will happen is probably this: Microsoft sends in their A-tier team to fix these problems ASAP. Eve may be an important showcase for them which they can't afford to lose.
Mashie Saldana Hooligans Of War	Posted - 2007.09.13 09:31:00 - [53] Edited by: Mashie Saldana on 13/09/2007 09:31:04 CCP has not said how big the DB is, however a few weeks ago one of the devs mentioned 150 million transactions per day. Light Assault Launchers & Defender FoF ideas
Bagdon Radical Fighters	Posted - 2007.09.13 10:46:00 - [54] Originally by: Grawshellar Originally by: Eventy One I up my wager to 200 ISK that MySQL should have been the DB of choice! I dunno, even die hard OSS fanatics I know who love MySQL for its nice performance on small-medium sized applications still ***** about its performance on a larger scale, and EVE defiantly falls into that category I'm a die-hard OSS fanatic. I write code for the second largest web service in my country with 1/3 of the population using our service each month. Switching away from MySQL was the best move we've ever done in the company. MySQL is crap. What we use now requires a bit more competence from our admins, but the life of the developers is so much easier now. And the performance. And the stability. And the quick failovers whenever hardware burns. And the stored procedures. And the cursors. And the slaves that aren't two days behind the master. tears of joy
Sainna Minmatar Brotherhood of the Void	Posted - 2007.09.13 16:32:00 - [55] Edited by: Sainna on 13/09/2007 16:33:00 Oops, wrong post. Drill Instructor: "If your nature didn't lead you to trample everyone in your path with vindictive glee, you might be tolerable.
Eventy One	Posted - 2007.09.14 07:15:00 - [56] Originally by: Faridah CCP is saying it's a DB problem. Which probably seems true since it's the DB who fall over and die, causing all the nodes to fall apart as they can't read/write to the DB. However, it seems this problem started at a certain date and after that date the servers haven't been up 23 hrs. Unless they did some major changes in the DB I would think it could also be a external issue. Everyone with a little knowledge of relation DBs know that a misscoded INNER JOIN could wreck havoc on any DB, including mySQL, posgres ..... Woah! Stop right there! You said the P-word! Cheers Eventy One
Lord Matrix Department of War	Posted - 2007.09.14 11:19:00 - [57] People saying that MySQL has no official support are wrong. MySQL Enterprise Gold offers the same services as the Microsoft's support solution. But of course, MySQL's InnoDB is slow in transactions which is why people should use SolidDB 6 for the fastest transaction database in the existace. It scales very well and is designed for high load sites. SolidDB also offers 24/7 technical support. ------------------------------------------------------------------ What good have you done for the EVE community today?

Pages: 1 [2] :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.