Jump to content
The Uniform Server Community


  • Content Count

  • Joined

  • Last visited

Everything posted by cookn22

  1. That is correct, on a 32bit OS individual processes have a RAM ceiling of 4GB (technically speaking. On windows it works out to be more like 3GB). This isn't a big deal for the Apache process, because if it's using that much RAM you're doing something wrong. On the other hand, it is a very big deal for MySQL, especially if you're wanting to use the InnoDB storage engine which needs to allocate a chunk of memory on initialization. As well, major performance gains can be made in MySQL by putting as much of your database into memory as possible to reduce hits on the hard drive - so, a 3GB-4GB ceiling on RAM usage by the MySQL process puts considerable limitations on how large the database can grow while still meeting performance needs. Unfortunately, getting a fully 64bit Apache/PHP/MySQL server running nicely on windows is a pain in the ass. If you check the official PHP/Apache sites, you'll notice there aren't official 64 bit binaries (not the case with MySQL, though). What the WAMP Server folks are doing is building their own 64 bit versions of Apache and PHP. Even with full control over the binaries and the build process it's STILL non-trivial to get the server running without a hitch. It can also be difficult to find/build 64 bit versions of needed Apache modules and PHP extensions. Altogether, providing 64bit WAMP package is alot of work, and seeing as the 32bit version of Uniform server is more than adequate for doing development work, I can understand why Uniform Server hasn't gone 64bit yet. So, if you want a 64bit Apace/PHP/MySQL Windows server, your choices are to build your own binaries, use a package like WAMP Server, or incorporate unofficial 64bit versions from some other source into the Uniform Server package. The best source for 64bit builds at this point in time is probably http://www.apachelounge.com/download/win64/. Recently, a forum user on that site built a 64bit version of PHP 5.4.4, which I've found to be remarkably stable when used as an Apache module. I've put together a Uniform Server package where I've replaced the 32bit versions of Apache/PHP/MySQL with 64 bit ones. Note that the MySQL version used in this package is the development release (5.6.5m8). I've left the 32 bit version of PHP in but renamed its directory to 'php32'. If the mod_fcgid module is loaded by apache, the 32bit binary in that directory is used (CGI). If mod_fcgid is not loaded, the 64bit version of PHP is loaded as an apache module. Check the Apache httpd.conf for some other minor changes (directories need 'ExecCGI' when mod_fcgid is used, for example). One thing I know for certain that still needs work is tweaking the MySQL config (my.ini). Here's a link to the package: http://dl.dropbox.com/u/24239603/server64.exe All the usual caveats related to using unofficial binaries apply. Also, if you need help with stability problems you should head over to the http://www.apachelounge.com/ forums, since that's where those 64bit versions came from.
  2. Winmerge is a great program that can make performing a manual upgrade of settings and files between server versions significantly less time consuming. Here's the main steps of the routine I go through whenever I update my UniServer installation to a newer version and need to maintain configuration settings and my site files/database tables: Assuming your old UniServer installation is currently running, open up phpMyAdmin, open the 'mysql' database, and export the user table with 'If not exists' checked under 'Create table options' and REPLACE set as the 'Function to use when dumping data'. You'll be importing this into the new mysql database later. If you're updating from 7.1.0 to 7.1.2, you should be able to do the same steps to copy-over rows from the 'event' and 'func' tables, though I've had weird issues with the 'func' table in the past, and I typically just do 'SHOW CREATE EVENT', copy those queries, and re-run them on for the new server install. In any event, we'll be backing up the new UniServer installation's mysql database in case anything weird happens. Stop and uninstall the Apache and MySQL services installed by your current (old) UniServer version. Don't trust that the UniServer program has done this successfully - open up the list of Services and double-check to make sure they've been removed. If either service is still there, follow the directions outlined here to remove them. Add '_old' to the name of your current (7.1.0) server directory (if it was 'UniServer', it would now be 'UniServer_old'). Next, create a new (empty) folder, give it the same name as the root directory for your old server installation (before adding '_old'), and finally unzip the new UniServer files into that directory. For any subsequent steps that involve moving folders and files from the '..._old' directory to the new UniServer directory, make sure you're copy/pasting them and not simply dragging and dropping them (which in most situations is equivalent to doing a cut/paste). Basically, in the event of a major screw-up or a rapidly approaching deadline, you want to have it so the only steps you need to do to restore the old UniServer installation (and your site) to working order are (1) stop and uninstall/delete the new installation's services (if you installed them) (2) temporarily rename the new UniServer's root folder (3) remove the '_old' suffix from the old installation's folder name (3) run the old UniServer's Start.exe -> and then install and run services. Copy your site's folders/files from '*_old/www/' to the www directory in the new Uniserver installation. Don't copy over any of the files or folders that come with the UniServer installation. If you've made edits to those files which you need to move to the new server install, you'll probably want to use WinMerge to safely transfer whatever edits or additions you made to the new server installation. Go to '*_old/usr/local' and copy-paste your old httpd.conf, php.ini and my.ini configuration files to the desktop. Add an '_old' suffix to the filename of each. Go to 'root/usr/local/...' in the new UniServer installation and create back-up copies of the same three config files. Then, copy-paste those three config files to the desktop (so, on your desktop you would now have 'php_old.ini' and 'php.ini', 'my_old.ini' and 'my.ini', etc). For each configuration file pair, select the old and new files, open up the right-click menu and click WinMerge. WinMerge will open and load the the old and new config files you selected. Using WinMerge, copy over any specific settings from the old config files to the new. When you're done, copy the modified config files back to their respective directories (apache, php or mysql). At this point you should have (for each of those three directories) a modified config file (copied from the desktop) and the copies you made of the unmodified config files which came with the server package. If anything weird happens, it's a simple matter to run WinMerge on the copies and the modified config files to determine if a config setting is to blame. Go to '*_old/usr/local/mysql/data' and select/copy the database directories used for your site, and paste them into the data directory in the new UniServer directory. Do not copy paste mysql, whatever_schema, or phpmyadmin. Do not copy any of the InnoDB-related files in .../mysql/data/', or the mysql.pid file. Run the new UniServer install's 'Start' executable, and then do 'Install and Run all Services'. Open up the UniServer admin panel, and check the settings for each page under 'Configurations'. Some of the settings will have been copied over by previous steps, but others won't. I usually only need to set the MySQL password at this point. Open up phpMyAdmin and do an export of the new UniServer's mysql database. This is simply so you can restore it in case things get weird while you're trying to import stuff from your old UniServer's mysql database. Import the user-table using the .sql file you exported earlier from your old UniServer installation. (also import 'event' and 'func' now, if you decided to export them earlier). To make sure table rows from your the old mysql database have been imported correctly into the new one, you should do 'Check table' for 'user' (and 'event'/'func' if needed), and then run 'Repair table' if any errors show up. Next, do 'Check table' and 'Repair table' on each of the tables in your site-specific database(s) (which were moved to the new UniServer install in step 8). After that, you should then do analyze/optimize on your site-specific database tables to get indexes/cardinality business back to where it should be. Those steps will usually do the trick. Some potential headaches are: If you run into 403 errors right off the bat, first open up your modified httpd.conf file and the copy you made of the unmodified version in WinMerge, and make sure you haven't overlooked anything there. Next, you can try running WinMerge on the whole old and new UniServer directories, and check for any .htaccess files which may need to be copied over (or WinMerge-ed) into the new UniServer installation. (this might also entail running WinMerge to compare the old and new 'htpasswd' directories). PHP extensions that worked beautifully on your old UniServer install can get weird when copied directly from the old server to the new. If you run into problems there, it's often a simple case of looking around the internets for more recent builds of the extension in question which are compatible with your version of PHP and whatever variety of Windows you're running. You may have set specific values in some of the configuration .php files that are in the 'root/home/admin/www' directory and its sub-directories (I have a handful of these for phpMyAdmin). If so, you'll need to poke around (if your memory is good) or use WinMerge to track down and copy the relevant lines of code from the old files to the new. The steps above that deal with the database will be sufficient in most cases, but you may very well run into weird behavior and errors. If you do, searching Stack Overflow and Server Fault will usually yield enough info to guide you in the right direction. Remember to export backups of any important tables before importing rows from the old UniServer installation. If you really screw things up, you can delete the entire '.../mysql/data' directory and replace it with the (unmodified) data directory as it is from the 7.1.2 (or 7.1.7) UniServer archive you downloaded. You'll need to restart MySQL in this situation. That might seem like alot of steps/work, however each step takes very little time (with the exception of copying over files and making backups, if your site is big).
  • Create New...