|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[ More Info ]
store.exe
consuming over 500 MB. This is happening at the moment on a Sunday evening when
few of the systems in the domain even have Outlook open to check email. The
CPU utilization is low, less than 10% at the moment when I am seeing the 500 MB
memory usage.
I've been seeing memory utilization jumping up to high values a lot lately.
Rebooting the system resolves the problem, but I don't want to be rebooting
the Exchange server every day. I can also reduce the memory utilization by
selecting Run and typing services.msc to bring up the
services list, I can then right-click on Microsoft Exchange Information
Store and stop the service and then restart it. I then see store.exe
using about 20 MB of memory when I check its utilization with the
Windows Task Manager
The Microsoft Exchange Information Store service manages the Microsoft Exchange Information Store, which includes mailbox stores and public folder stores. If the service is stopped, mailbox stores and public folder stores on the computer become unavailable, so it needs to be restarted immediately after stopping it.
References:
[Sat Apr 26 21:53:00 2008] [error] [client 192.168.0.44] calendar debug 1:
start() called, enabled
[Sat Apr 26 21:53:00 2008] [error] [client 192.168.0.44] calendar debug 1:
filter() called
[Sat Apr 26 21:53:00 2008] [error] [client 192.168.0.44] Byte order is not
compatible at ../../lib/Storable.pm (autosplit into
../../lib/auto/Storable/_retrieve.al) line 331, <DATA> line 32, at
/home/jsmith/www/blosxom/plugins/calendar line 322
[Sat Apr 26 21:53:00 2008] [error] [client 192.168.0.44] Premature end of
script headers: blosxomAt [ic] HELP !FreeBSD 5.3 Box With newest version of perl storable problem , I saw the following:
You appear to have a perl configured to use 64 bit integers in its scalar
variables. If you have existing data written with an earlier version of
Storable which this version of Storable refuses to load with a
Byte order is not compatible
error, then please read the section "64 bit data in perl 5.6.0 and 5.6.1"
in the Storable documentation for instructions on how to read your data.
(You can find the documentation at the end of Storable.pm in POD format)That revealed that the problem was linked to the fact that I am now using a 64-bit operating system.
I decided to see if an upgrade Storable module was available.
# cpan upgrade Storable
/usr/lib/perl5/5.8.8/CPAN/Config.pm initialized.
CPAN is the world-wide archive of perl resources. It consists of about
100 sites that all replicate the same contents all around the globe.
Many countries have at least one CPAN site already. The resources
found on CPAN are easily accessible with the CPAN.pm module. If you
want to use CPAN.pm, you have to configure it properly.
If you do not want to enter a dialog now, you can answer 'no' to this
question and I'll try to autoconfigure. (Note: you can revisit this
dialog anytime later by typing 'o conf init' at the cpan prompt.)
Are you ready for manual configuration? [yes]I entered "no" to the prompt regarding whether I was ready for manual configuration, which resulted in the autoconfigure process proceeding.
I then checked Storable again.
# cpan Storable
CPAN: Storable loaded ok
Going to read /root/.cpan/Metadata
Database was generated on Sat, 26 Apr 2008 17:29:46 GMT
Storable is up to date.I checked the version of the module with perlmodver. The version was 2.18.
But the problem still remained. Taking a look at the code in the calendar
plugin, I realized it was reading a file, .calendar.cache in
the plugins/state directory. I had not noticed the file previously,
because I had checked the directory's contents only with ls. I
saw it with ls -a. The calendar plugin reads the contents of
that file. I had copied the file from the old 32-bit system to the new 64-bit
system when I copied the plugins directory and its subdirectores. When I
deleted the .calendar.cache file from the state
directory and then tried accessing the blog again, the calendar plugin
recreated it, but this time it was in the proper 64-bit format that the
Storable.pm module was expecting, so I was now able to view
the blog with the calendar functionality now working.
Further information on the issue can be found near the end of the
Storable.pm file (look in
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Storable.pm).
Perl 5.6.x introduced the ability to optional configure the perl interpreter to use C's C<long long> type to allow scalars to store 64 bit integers on 32 bit systems. However, due to the way the Perl configuration system generated the C configuration files on non-Windows platforms, and the way Storable generates its header, nothing in the Storable file header reflected whether the perl writing was using 32 or 64 bit integers, despite the fact that Storable was storing some data differently in the file. Hence Storable running on perl with 64 bit integers will read the header from a file written by a 32 bit perl, not realise that the data is actually in a subtly incompatible format, and then go horribly wrong (possibly crashing) if it encountered a stored integer. This is a design failure.
Storable has now been changed to write out and read in a file header with information about the size of integers. It's impossible to detect whether an old file being read in was written with 32 or 64 bit integers (they have the same header) so it's impossible to automatically switch to a correct backwards compatibility mode. Hence this Storable defaults to the new, correct behaviour.
What this means is that if you have data written by Storable 1.x running on perl 5.6.0 or 5.6.1 configured with 64 bit integers on Unix or Linux then by default this Storable will refuse to read it, giving the error I<Byte order is not compatible>. If you have such data then you you should set C<$Storable::interwork_56_64bit> to a true value to make this Storable read and write files with the old header. You should also migrate your data, or any older perl you are communicating with, to this current version of Storable.
If you don't have data written with specific configuration of perl described above, then you do not and should not do anything. Don't set the flag - not only will Storable on an identically configured perl refuse to load them, but Storable a differently configured perl will load them believing them to be correct for it, and then may well fail or crash part way through reading them.
