On Wed, Mar 28, 2007 at 07:21:56PM +0530, Siju George wrote: > Thanks a million Roberto for the Quick Reply :-) > No problem.
> On 3/28/07, Roberto C. Sánchez <[EMAIL PROTECTED]> wrote: > >> > >The hardware specs look good. How much bandwidth will the server have > >going to it? I mean is your ISP connection a dedicated T1, T3, or > >something else? > > > > T1 burstable they say. That is more bandwidth will be automatically > alloted if needed. > OK. I am not sure if a connection that small can handle a slashdotting, but I guess you will find out :-) > >> So I hope I should be Installing ( right? ) > >> > >> kernel-image-2.6.8-12-amd64-k8-smp - Linux kernel image for version > >> 2.6.8 on AMD64 SMP systems > >> > >> to harness the full power of the CPU as currently it shows only > >> > >You want to be using Etch. > > > > May I Know why Is ther any problem using Sarge? > isn't that more stable. > Etch will be released any day now. You will save yourself much grief if you just start off with Etch than starting with Sarge and trying to upgrade to Etch. There have been some very major changes. > I never used Etch for Production Servers. > > I already upgraded one Server to the Sarge SMP kernel. > Should I be using Etch Instead? > I would recommend yes. Etch already has security support, which is usually the biggest issue when choosing something for production. Other than that, it is quite stable, including newer versions of Apache and PHP, which should give you better performance. > > I am a bit apprehensive about using Etch in Production :-( > Also the freequent kernel upgrades to Etch would mean freequent reboots > right? > Umm, there should be no more kernel updates to Etch. The final kernel was set some time ago and I believe that all the updates are done for the time being, excepting possible future security fixes. > >> I hope to Install LVM and have seperate partitions for > >> "/var/log" and "/var/www" so I can adjust them if there is any need in > >> future. > >> > >Put everything on LVM. That allows you to create separate partitions as > >necessary. > > > > http://tldp.org/HOWTO/LVM-HOWTO/benefitsoflvmsmall.html > > says > =========================================== > "root on LV should be used by advanced users only > > > root on LVM requires an initrd image that activates the root LV. If a > kernel is upgraded without building the necessary initrd image, that > kernel will be unbootable. Newer distributions support lvm in their > mkinitrd scripts as well as their packaged initrd images, so this > becomes less of an issue over time. " > ======================================================================= > > Is it outdated info? > > or shall I put > > /boot on an Ext3 > > and put the rest in LVM on XFS > Actually, you are right. My response was too terse. Having / on LVM, while it has become easier to manage, is not something that I am yet comfortable with. If your install has some sort of major catastrophic failure, having / on LVM is just another complication. In your case, I would recommend /boot (ext2) and / (ext3 or xfs) be each their own non-LVM partitions. Everything else should be on LVM. Also, I forgot to mention that you should only use XFS if the system is on a good UPS. > >> What do you suggest use up the whole 500 GB disks or leave some free > >> Space for later use? > >> > >I would say, start with the partitions as small as you can. Use XFS and > >grow the partitions as necessary. > > > > Thankyou so much :-) > hope Linux Can boot From XFS and kernel upgrades will go without probs. > and also handle kernel upgrades will go smoothly. > Yes. XFS has been in the mainline kernel since about version 2.4.24 or 2.4.28 (I forget which), and grub has supported it for a long time now. > > > > >If you have any choice in the matter, use Python or Perl instead of PHP > >so that you can use apache's worker MPM, which by all accounts should > >perform lots better. > > > > nope :-( the code is already in PHP. > > >At the risk of starting a flameware, please don't use MySQL. That is, > >unless you are a super experienced expert. It is well known that > >MySQL's performance drops very quickly as the number of connections > >increases. This can be mitigated with clustering and performance tuning > >(for example, slashdot uses a MySQL cluster and they have been > >performance tuning it for like 8 years). However, since you have only > >one server, you really want a database that will scale well in one > >instance. For that, I can recommend PostgreSQL > > > > Really? > I heard postgresql is slower than mysql. not true? Right, that is not true. For a small number of users or connections, MySQL is actually a bit faster, but this represents a very small number of use cases. Also, much MySQL's speed comes from its poor (or non-existent) handling of data integrity. You can, however, compensate for the data integrity in your application code. > any way the code is written for php5, mysql5 so no choice :-( > I'm not sure how your code is written. If a new connection is opened to the MySQL database for each client connection, your database will likely crawl once you get several hundred users accessing the site simultaneously. If you are able to have some sort of connection pooling set up, then that should help tremendously, since the various sessions will continually reuse the same small number of connections. > Thanks a million :-)))))))))))))))))))))))))))) > No problem. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
signature.asc
Description: Digital signature
