Updated: 10/23/15
I reinstalled the OS on my OS X server and upgraded to 10.10 Yosemite. In that process I had to reinstall the Backup Exec agent, and I'm still running 2010. It was quick and simple, even though I ran into the same error about Switch.pm missing. Since it's been so long I looked it up rather than referring back to this post, and found an easier command than below on this blog. In Terminal, run sudo cpan -f Switch. You'll likely get a message that says something about your system needing XCode installed, and you'll have to select Install. Once that finishes, re-run sudo cpan -f Switch and let it autoconfigure itself. Once done, go ahead and run the Backup Exec Agent installer and any service packs you have for it and it should work just fine. Make sure to start the agent when you're finished.
Original Post:
If you're like me and hated the newer interface Symantec introduced in Backup Exec 2012, you may still be running Backup Exec 2010 instead. Now, if that's the case and you introduce a new Mac running OS X 10.9 Mavericks into your list of machines to backup you're going to run into a problem. The BE2010 agent will not install in OS X 10.9 and will give an error message instead about not being able to locate Switch.pm. Before you jump to the conclusion that you need to upgrade Backup Exec to a version compatible with OS X 10.9, keep reading.
I ran across this today with a new OS X 10.9 Mac Mini server. It turns out that in Mavericks the Switch.pm has been deprecated from the version of Perl that comes with the OS, and the RAMS agent installer relies on that to run. It also turns out that adding it back to the OS is a pretty simple process, and once done the RAMS installer runs just fine. Here's what I did
1. Open a Terminal window on the OS X server
2. Run the command cpan install
3. Follow through the on-screen setup for CPAN (Comprehensive Perl Archive Network). I used the defaults
3a. During the install you will be prompted by the OS that you need to install make in order for the installer to continue. Click OK and let make install
4. Now CPAN should be installed so start it with sudo cpan. You need sudo access to install the Switch.pm file
5. You should see cpan (1) >. Type install Switch and press Enter. This will install the missing module back
to your Perl library
6. Once that's done type quit and press Enter to get back to the main Terminal
Now you should be able to run the RAMS installer package normally, and this time it should work.
Before doing this though, you should really ask yourself if you should. It seems to be working fine for me, but the Switch module was deprecated and left out for some reason. I make NO guarantees about this process, other than that it worked for me. If you have a test network available, please make sure to utilize that first before making this change in your production environment. Like I said, this was figured out the same day that I posted it, so I haven't done enough testing to say that it won't adversely effect the system, RAMS performance, or both.
This is the original article I came across while trying to get the RAMS installer to work that led me to write this article.
Monday, June 30, 2014
Monday, June 9, 2014
Free up inactive memory in OS X
Let me preface this by stating that normally you should not have to do this, and it is typically best to let the OS manage the RAM usage. I suggest you use this method only when necessary rather than as a standard practice. I'm also making an assumption that your familiar with the Terminal app, primarily in the situation where you want to schedule this. If you are not, you may need to do some research on Terminal outside of this post.
If you're like me, you've had an issue on an OS X server and when you check it out there is little to no free RAM available but you have a bunch stuck in the state known as inactive memory. This typically indicates one of two things. Either you need more RAM to run your server applications effectively, or something is causing a memory leak. In my case it is a little of both. However, running out and picking up Apple Server memory on a whim isn't always an option. Tracking down a faulting program isn't always easy, or quick either. If you're struggling to keep an OS X server accessible while waiting for an upgrade window or to give yourself time to troubleshoot, or if you're having problems with the personal Mac's memory allocation, this may be a temporary workaround you can use.
There is a command named "purge" that will free up the inactive memory. You can read more about it on the purge man page. You can simply open Terminal and issue the command, then press Enter. You may need to use sudo purge, but nonetheless you can invoke purge and free up some RAM immediately.
However, if this is a server or continues happening, you may want to script this command and call it on a schedule. While waiting for a shipment of RAM for a couple OS X servers having this issue, I used this script provided by Daniel Payne on stackoverflow.com in this article.
I opened Terminal and used vi to create the script file, but you should be able to use Textedit or any text editor you'd like. Just make sure to name it with the extension of .sh at the end, so your file should be named something like freeRAM.sh. What this script does is run the purge command if there are less than 18000 free memory pages available. You will want to modify that value to match the minimum amount of memory you will accept before running the command. This eliminates unnecessary running of the purge command. Remember that this is the value in memory pages, not B/KB/MB/GB. If you don't know page size your system is using, you can run vm_stat within Terminal and it will tell you in the first line. For my server I was using the default page size of 4096 bytes. This means that if I wanted to run the purge command if there was less than 200MB of free memory, I would need to substitue the 18000 in the script above with
200MB * 1024KB/1MB * 1024B/KB * 1PG/4096/KB = 51200 (instead of 18000)
Once you have your shell script saved you need to add it to the schedule. You can use cron, but it appears to be deprecated in newer version of OS X so instead we'll use launchctrl. I used the guide found here to create my .plist file and get it into the launch daemons schedule.
You can also create your script using Automator and then schedule it using iCal. However, I wanted to run the script multiple times a day, and it appears that using iCal allows once a day as the most frequent option.
If you're like me, you've had an issue on an OS X server and when you check it out there is little to no free RAM available but you have a bunch stuck in the state known as inactive memory. This typically indicates one of two things. Either you need more RAM to run your server applications effectively, or something is causing a memory leak. In my case it is a little of both. However, running out and picking up Apple Server memory on a whim isn't always an option. Tracking down a faulting program isn't always easy, or quick either. If you're struggling to keep an OS X server accessible while waiting for an upgrade window or to give yourself time to troubleshoot, or if you're having problems with the personal Mac's memory allocation, this may be a temporary workaround you can use.
There is a command named "purge" that will free up the inactive memory. You can read more about it on the purge man page. You can simply open Terminal and issue the command, then press Enter. You may need to use sudo purge, but nonetheless you can invoke purge and free up some RAM immediately.
However, if this is a server or continues happening, you may want to script this command and call it on a schedule. While waiting for a shipment of RAM for a couple OS X servers having this issue, I used this script provided by Daniel Payne on stackoverflow.com in this article.
#!/bin/bash
free=`vm_stat | grep free | awk '{print $3}'`
freer=${free%%.*}
if [ "$freer" -lt "18000" ]
then
nice purge
fiI opened Terminal and used vi to create the script file, but you should be able to use Textedit or any text editor you'd like. Just make sure to name it with the extension of .sh at the end, so your file should be named something like freeRAM.sh. What this script does is run the purge command if there are less than 18000 free memory pages available. You will want to modify that value to match the minimum amount of memory you will accept before running the command. This eliminates unnecessary running of the purge command. Remember that this is the value in memory pages, not B/KB/MB/GB. If you don't know page size your system is using, you can run vm_stat within Terminal and it will tell you in the first line. For my server I was using the default page size of 4096 bytes. This means that if I wanted to run the purge command if there was less than 200MB of free memory, I would need to substitue the 18000 in the script above with
200MB * 1024KB/1MB * 1024B/KB * 1PG/4096/KB = 51200 (instead of 18000)
Once you have your shell script saved you need to add it to the schedule. You can use cron, but it appears to be deprecated in newer version of OS X so instead we'll use launchctrl. I used the guide found here to create my .plist file and get it into the launch daemons schedule.
You can also create your script using Automator and then schedule it using iCal. However, I wanted to run the script multiple times a day, and it appears that using iCal allows once a day as the most frequent option.
Subscribe to:
Posts (Atom)