On Sat, Jun 11, 2011 at 12:45 PM, Lamar Owen <[email protected]> wrote: > On Friday, June 10, 2011 08:29:49 PM you wrote: >> It's problematic, especially if one leaves >> the 32-bit versions of components and libraries dual-installed with >> the 64-bit, deletes one and not the other. > > Multilib support can indeed be a problem. In a very large memory system one > would be wise to make sure that the system is 'pure' 64 bit on x86_64. > (other 64-bit systems vary as to recommendations.....) > >> The codebase for SL 5 and >> RHEL 5 uses significantlyou out of date kernels, glibc, and other core >> utilities. so yes: if you stretch the environment beyond the common >> resources at the time it was originally designed, you can enter the >> world of surprising corner cases. > > Given the fact of backporting, how 'out-of-date' the kernel, glibc, and other > core utilities are is difficult to determine. But one person's out-of-date > is another's 'stable' instead. Reminds me of this VAX in the corner, driving > a microdensitometer.... > > But that doesn't address the problem for the OP: why does SLC5.6 see things > so differently than upstream's code of the same version and built from the > same source? That's what the OP was asking about; and I'm looking forward to > seeing the OP post back about any new information.
Me, too. I'm not assuming that our OP actually had identically configured RHEL 5.x and SL 5.x environments. But the CD based reports are interesting. > But what were the 'common' resources at the time of EL5's initial release? > What were the 'extreme' resources? IA64 systems were certainly available > with >32GB of RAM prior to EL5's introduction. I specified and got quoted an > Appro quad socket Opteron system with 64GB of RAM a year or more before EL5's > introduction in November of 2007; it was very expensive, too, with over 75% > of the cost of the whole machine being RAM, at the time. And my current > VMware hosts are a little over 4 years old; and they have 32GB of RAM (Dell > PE6950's, quad socket dual-core Opterons; wouldn't mind upgrading to quad > core or hex core chips if they were supported, and 64GB of RAM is an option > with all four sockets populated as they are). And those PE6950's shipped 8 > months before EL5.0 went GA. That may not have been common, though; I do > know they were expensive. But Dell at least has been pretty good about > keeping drivers, BIOS's, and other critical things like SAS controller and > DRAC firmware updated through the years, even for that hardware. It was bloody expensive. Let's see, 4 years ago.... I'd finished some work helping build, and design, blade servers, including a lot of RHEL 4 and some singificant SuSE integration. 8 Gig was considered hefty: 64 Gig was considered wonderful because they were so expensive and the profit was so high. > Uptime junkies need to get a life. Uptime isn't the be-all, end-all.....even > if it is a part of the whole availability equation.... As you probably agree, > Nico. In an HA VMware situation, uptime of the hosts, as long as the > downtime is planned, is a non-issue. That should be valid for other > virtualization solutions, too, as long as you've configured it HA. Virtualization and its high availability is useful, but also not a be-all and end-all. It doesn't exercise kernels, it doesn't break locks, and if some error has eroded your filesystem, it doesn't give you a chance to fsck unless you actually reboot. It *does* massively reduce the cost of a reboot.
