While we are at this, once it happened to me to give some disk space to a DBA. That space was in a big storage, all baked by solid state disks. The day after i did it i got called from the DBA who started whining that it was slow. Went to his office and he showed me the "proof". It was this:
$ dd if=/dev/zero of=file_on_ssd count=8196000
Seems you've know only lame sysadmins. Like i've seen bad dba's. And judging on the RAID part of your comment (wich is something new for me and no, i'm not being sarcastic) seems you're talking about small servers. In my sysad experience, oracle or such had always been assigned some LUN from a big storage, on which i have no control and neither the expertise to configure. RAID is done in there, in hardware for the part involving HA as minimum. All i can do is volume management, chown that LUN (if raw partitions in use, or FS if not) to oraadmin and build the stripes based on the indications i get from the storage guy.
Trivial things like shared memory limits and such i know
Amen to that.
And even when you are right, it's you who have to proof it as you're the last arriving one in the place, possibly in a way that does not hurt the other guy.
Never been working on network (well, professionally i mean) but nearly always when there is some network problem NOC and NOC people get called, first thing they say is that there is no malfunction on our part. And strange enough problems get resolved after 5/30 minutes after the call.
Now, reading the post of a net guy and knowing the reaction of normal loosers that first thing to blame is the network i can understand why it is so. But when someone from operations calls means (i hope at least) that i've gone at least the burden of checking iptables/pf/ routes, ping, ndd, ethtool kstat, arp and all before bothering another soul like me.
Though people act different, i cant speak just for me.
[...]
More generally, we have a fundamental problem in the I/O area: UNIX. UNIX I/O has a very simple model, which is now used by Linux, DOS, and Windows. Everything is a byte stream, and byte streams are accessed by making read and write calls to the operating system. That was OK when I/O was slower. But it's a terrible way to do inter-machine communication in clusters today. The OS overhead swamps the data transfer. Then there's the interaction with CPU dispatching. Each I/O operation usually ends by unblocking some thread, so there's a pass through the scheduler at the receive end. This works on "vanilla hardware" (most existing computers), which is why it dominates.
This is true. Though you're underestimating "modern" os's. Though, think of it as defensive planning. Who knowed ~20+ years ago that we would have solid state disks? Who knowed we would have 10GB NICs? SATA?
But the foundamental design of IO streams works and is easily adapted on new devices. Add on that the simplicity of
[...]
The supercomputer interconnect people have been struggling with this for years, but nothing general has emerged.
RDMA via Infiniband is about where that group has ended up. That's not something a typical large hosting cluster could use safely.
Add to that fibrechannel. And NUMA is an old and tried technology.
Most inter-machine operations are of two types - a subroutine call to another machine, or a queue operation. Those give you the basic synchronous and asynchronous operations. A reasonable design goal is to design hardware which can perform those two operations with little or no operating system intervention once the connection has been set up, with MMU-level safety at both ends. When CPU designers have put in elaborate hardware of comparable complexity, though, nobody uses it. 386 and later machines have hardware for rings of protection, call gates, segmented memory, hardware context switching, and other stuff nobody uses because it doesn't map to vanilla C programming. That has discouraged innovation in this area. A few hardware innovations, like MMX, caught on, but still are used only in a few inner loops.
At the cost of my mood points or whatever, now i call bullshit.
Rings protection? Used at least in linux.
Call gates? You mean Sysenter? Used at least in linux from ~2002 if im not wrong
Segmented memory? Hello 32bits? Is that what you mean? Correct me if im wrong, but i thought it was a thing of the past.
Hardware context switching? You mean VMX (AMD) or SVM (Intel) ? At least on Linux those instructions are used.
C is the limiting on this? Please.
MMX? SSE/2 etc?
gcc -mmmx -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2
(talking about gcc because that is what i know, though im sure other compilers cane use those instructions too)
It's not that this can't be done. It's that unless it's supported by both Intel and Microsoft, it will only be a niche technology.
yep right.
true, mine was a one word comment. Let's expand.
Putting aside WW, where the serbian guy was just an excuse.
Fast forward at late 80's. See how it went with Yugoslavian federation. After Tito's death came in scene Slobo.
That meant war with Slovenia (lucky them, Croatia was closer to Serbia), war with Croatia, war with Bosnia, Macedonia was lucky as in between they had Kossovo, war with Kossovo. Lucky Montenegro that got out from that confederation with harm.
Judge by yourself about peace & Serbia.
Now mod me down to frost.
together with the (mostly proffessional and helpful) people that were working behind.
[...]
So, I wouldn't be surprised if we see raids, confiscation of computer equipment and (in the UK, at least) charges brought under the Computer Misuse Act. I wonder what the average decline in income is, due to one's inability to get certain jobs because of a criminal record.
Same as the income of RIAA suing grandmothers. Probably a good outcome for most after all.
ulimit is your friend
It's used for the sound.
Sorry, couldn't resist
You make absolutely no sense.
People using Oracle will be buying SUN hardware in their next upgrade, it's what Oracle says they must use, it will be what they are using - that's the whole point of buying Oracle, they take the blame if it doesn't work, but you *must* buy their medicine.
Oracle says that linux is fine, and each and every release of redhat is supported. That is what i am seeing. Sure, you buy the DB, no escape from that.
But hey you genius, tell me, where are Oracle advertising "their" hardware? I must be missing something.
If we are using emperical evidence, I would make the claim that no one is using Oracle in corporations, because I've never seen anyone use it when working for mega corps. I have however seen MySQL, DB2 and MSSQL - but unlike you I'm very well aware that it makes no sense to make such claim.
Cool down, i was just saying what i see around. Nice to see there are other setups around, indeed, i'm glad for this, i'm not a fan of Oracle.
And your last comment about DBA - again, you make no sense. Why was an entire DB being imported on a live environment? Would you rather have had a single commit in the end? If this was such a "huge DB" (I'm thinking TB when talking huge), he might only have had the option of a single commit or autocommit; in which case autocommitting is the correct option, since the rollback tree for a TB class DB would destroy everything.
Where did i said it was a live environment? Where did you got it? Talking about an import?
You seem to have a nice crystal ball.
No. Nobody's moving away from Oracle - that rhetorical question doesn't make you sound like a smartass, but rather its less intelligent opposite.
What matters to Oracle's customers who buy Sun hardware is that their databases run as fast as possible, as that's the limiting factor on those customers' businesses.
Bullshit. Who is buying SUN hardware anymore after their buyout? And after Oracle changed prices on the OS?
That's why Oracle bought Sun: to compete with IBM, which runs DB2 on IBM CPUs at the high end, the HW and SW tweaked to work best together for that operation.
Maybe I'm young, or whatever, but in all the "big enterprise costumers" where i've been working i've never ever seen a DB2. I have seen in order of frequency: Oracle DB from ~8 to 11r1 then Sybase. On this operating systems, in order of frequency: Solaris, HPUX, Linux, AIX.
All of them had a DB supporting SAP BTW, and there i think Oracle is pointing.
Reducing the number of cores isn't designed to help. It's designed to leave that amount of transistors on the CPU available for making Oracle DBs run as fast as possible in the few simultaneous threads that Oracle needs for DB performance.
As I'm not a DBA i cant say much on that. Though i remember a performance problem related on what you're saying. But it turned out the DBA was doing an import of a huge DB with AUTOCOMIT=1.
Oracle is not selling CPUs to the mass market that can't tell the difference among products, mostly because they don't have a benchmark that describes their use profile specifically. Oracle is selling to customers who pitch $:TPM to their bosses. And the $:TPM buzzword is not only not going out of style, it's what continues to drive $ to Oracle.
Solaris is a great OS and you're right on the CEO part.
Too bad they didnt GPL'd their SO before getting sold.
I'll miss their HW/SW stack. Sad for this.
Though linux is getting confortable now.
Serbia?
Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?
