J
Juliet Ellis
Hello everyone,
this may just be too complicated (or maybe not ?) to post to this
group.
These are my pasted notes of the problem.
These are comments from 6/1/04. We weren't in a lab environment so be
careful to draw absolute conclusions from what we found: too many
variables to be totally reliable.
The machines are NT4 SP6, Office SR2, NetWare client 4.83 SP2 E pack.
NetWare 5. Dual-processor Xeons, 1GB RAM HP sw6000s. They were built
specially for Excel so are installed differently to rest of company
that uses a standard build.
1) The problem is with many (36GB worth) large, complex Excel files as
per above notes residing on 89 - A NetWare server. Errors
range from the Dr. Watson detailed above to "Data may be lost", "Not
enough memory" "File cannot be
read", "File cannot be opened". They haven't reported problems with
any other files so
unfortunately we cannot conclude that this is Excel-specific.
Sometimes files will open and then
fail with a Dr. Watson within minutes.
2) The files can usually be opened from C:
3) They can usually be opened from a mapped NT source (MS RPC calls)
4) They can be opened with the XP trial PC in same business section
and VLAN and our standard NT builds.
5) This is the Year End and Month End period when the files are at
their maximum size. Once processsed they will begin 2004 with 'empty'
files. The problem came about in December (suggests
the Excel files) when the files are at their peak.
6)The NT build on the SW6000 HP Workstations appears to always connect
to 89 (Finance server) with IPX unless IP is forced. On our other
builds IP was invariably the transport of choice. Reason ?
7) The Network port checked out OK for the troubleshooting PC.
8) Possibly the NT build is using some Win2000 drivers, perhaps for
the Gigabit Ethernet card. We didn't build the PCs. External company
but we must support them.
9) We uninstalled IPX and found the same problem continued.
10) Updated the client to business standard (i.e. E pack): no change
11) Removed and re-installed client: no change.
12) Flow Control on the NIC was set to OFF: changed to Auto.
13) Increased and moved the swap file to D:\ because of the "Not
enough memory"
14) We intended to move their directory structure across to an NT
server to take IPX and 89 out of the loop but when we started we
realised NT110 didn't have enough capacity for their 36GB (Windows
Explorer measure) of files. As the Excel files are generally linked to
other files they couldn't easily/were unwilling to rationalise a
smaller group of files to move to NT110. It would
have potentially been quite messy to have some Excel files save to
their G: and then other saved to T: (nominated for NT110). Could
easily have led to inconsistencies of data if a user forgot just
once when opening/saving a file. Server team looked for alternate
space but only the live intranet and Exchange DR servers have the
capacity but can't be used.
15) We decided to replace the workstations with standard XP build
HP530s from store. Initial testing seems all good. Performed better.
When
selecting Calculate sheet the progress bar is stuck on 0% for about 3
minutes but then completes OK. (Task Mgr indicates Excel is Not
Responding).
16) Some files become corrupt (cannot be opened) after a short period
(1,2,3 days). This could be
happening locally, be the nature of the files or maybe something to do
with the collaborative
working style. Also consider what is happening during the lengthy
reading/writing from 89 with
these NT builds.
I don't believe there is a problem with 89 as we can work on the
volume OK from our NT and XP
builds.
We need to identify 1 file that is consistently failing on the Xeon
workstations and is
consistently working elsewhere before continuing. (However there is a
slightly random factor in the
error occurence)
I couldn't find guidelines on Microsoft/ www about Excel97 limitations
with regard to add-in
templates, linking, OLE, calculations etc when the workbooks already
have thousands of rows per
sheet. (these have complicated workbooks: OLE links to Access,
additional templates, thousands of rows on multiple sheets, many
macros running.)
In a plain vanilla sheet 65,536 rows is the limit, although memory
problems could crop up before
this is reached.
Excel has its own memory manager and its own memory limits (max 64MB)
so throwing hardware at his
own't cure memory problems. Each instance is also limited to 32,760
source cells when you perform a
smart fill operation. Using Zoom ( ie Zoom NOT at 100%) sometimes uses
a lot of memory. Large
autofills (limit is 32760 source cells). Memory leaks occur when
opening and closing workbooks. I
suspect some Finance users are in and out of various XL files through
a day and may benefit from
restarts.
If the users can work OK for a sustained period on these files with
the XP build then we can
probably discount this being a factor. However in practice they only
need these files short-term
(until next year and the same problem occurs).
I would like to run Performance Monitor to record Network and local
metrics whilst the user is
working with Excel for a period.
We don't have access to a later version of Excel. If still using XL97
they should reduce the size of the worksheets (spread over
multiple sheets). In a workbook, the total of all of the formulas in
the workbook must refer to
less than 16,375 unique cells in any worksheet in any other closed
workbook.
Opening 2nd/3rd instance of Excel is less restrictive with memory
(64MB max per instance) than
their current practice of opening a second/third file within one Excel
session. The sessions will
work independently of each other. Need to explain this to Excel
power-users. Excel will only use
64MB to process its work. Also in case of out of memory messages when
opening workbooks with
external links (i.e. typical to Finance) they should open the linked
to workbooks before opening
the wanted workbook file. Not sure if this can be done in other
instances.
http://support.microsoft.com/?kbid=167079
http://www.decisionmodels.com/memlimitsc.htm
Example error log:
Application exception occurred:
App: excel.dbg (pid=316)
When: 1/5/2004 @ 14:51:33.812
Exception number: c0000005 (access violation)
FAULT ->30103eed 8b06 mov eax,[esi]
ds:093fcc54=????????
If anyone has any advice (please not "Buy Excel 2003") that would be
great
(e-mail address removed)
Juliet
this may just be too complicated (or maybe not ?) to post to this
group.
These are my pasted notes of the problem.
These are comments from 6/1/04. We weren't in a lab environment so be
careful to draw absolute conclusions from what we found: too many
variables to be totally reliable.
The machines are NT4 SP6, Office SR2, NetWare client 4.83 SP2 E pack.
NetWare 5. Dual-processor Xeons, 1GB RAM HP sw6000s. They were built
specially for Excel so are installed differently to rest of company
that uses a standard build.
1) The problem is with many (36GB worth) large, complex Excel files as
per above notes residing on 89 - A NetWare server. Errors
range from the Dr. Watson detailed above to "Data may be lost", "Not
enough memory" "File cannot be
read", "File cannot be opened". They haven't reported problems with
any other files so
unfortunately we cannot conclude that this is Excel-specific.
Sometimes files will open and then
fail with a Dr. Watson within minutes.
2) The files can usually be opened from C:
3) They can usually be opened from a mapped NT source (MS RPC calls)
4) They can be opened with the XP trial PC in same business section
and VLAN and our standard NT builds.
5) This is the Year End and Month End period when the files are at
their maximum size. Once processsed they will begin 2004 with 'empty'
files. The problem came about in December (suggests
the Excel files) when the files are at their peak.
6)The NT build on the SW6000 HP Workstations appears to always connect
to 89 (Finance server) with IPX unless IP is forced. On our other
builds IP was invariably the transport of choice. Reason ?
7) The Network port checked out OK for the troubleshooting PC.
8) Possibly the NT build is using some Win2000 drivers, perhaps for
the Gigabit Ethernet card. We didn't build the PCs. External company
but we must support them.
9) We uninstalled IPX and found the same problem continued.
10) Updated the client to business standard (i.e. E pack): no change
11) Removed and re-installed client: no change.
12) Flow Control on the NIC was set to OFF: changed to Auto.
13) Increased and moved the swap file to D:\ because of the "Not
enough memory"
14) We intended to move their directory structure across to an NT
server to take IPX and 89 out of the loop but when we started we
realised NT110 didn't have enough capacity for their 36GB (Windows
Explorer measure) of files. As the Excel files are generally linked to
other files they couldn't easily/were unwilling to rationalise a
smaller group of files to move to NT110. It would
have potentially been quite messy to have some Excel files save to
their G: and then other saved to T: (nominated for NT110). Could
easily have led to inconsistencies of data if a user forgot just
once when opening/saving a file. Server team looked for alternate
space but only the live intranet and Exchange DR servers have the
capacity but can't be used.
15) We decided to replace the workstations with standard XP build
HP530s from store. Initial testing seems all good. Performed better.
When
selecting Calculate sheet the progress bar is stuck on 0% for about 3
minutes but then completes OK. (Task Mgr indicates Excel is Not
Responding).
16) Some files become corrupt (cannot be opened) after a short period
(1,2,3 days). This could be
happening locally, be the nature of the files or maybe something to do
with the collaborative
working style. Also consider what is happening during the lengthy
reading/writing from 89 with
these NT builds.
I don't believe there is a problem with 89 as we can work on the
volume OK from our NT and XP
builds.
We need to identify 1 file that is consistently failing on the Xeon
workstations and is
consistently working elsewhere before continuing. (However there is a
slightly random factor in the
error occurence)
I couldn't find guidelines on Microsoft/ www about Excel97 limitations
with regard to add-in
templates, linking, OLE, calculations etc when the workbooks already
have thousands of rows per
sheet. (these have complicated workbooks: OLE links to Access,
additional templates, thousands of rows on multiple sheets, many
macros running.)
In a plain vanilla sheet 65,536 rows is the limit, although memory
problems could crop up before
this is reached.
Excel has its own memory manager and its own memory limits (max 64MB)
so throwing hardware at his
own't cure memory problems. Each instance is also limited to 32,760
source cells when you perform a
smart fill operation. Using Zoom ( ie Zoom NOT at 100%) sometimes uses
a lot of memory. Large
autofills (limit is 32760 source cells). Memory leaks occur when
opening and closing workbooks. I
suspect some Finance users are in and out of various XL files through
a day and may benefit from
restarts.
If the users can work OK for a sustained period on these files with
the XP build then we can
probably discount this being a factor. However in practice they only
need these files short-term
(until next year and the same problem occurs).
I would like to run Performance Monitor to record Network and local
metrics whilst the user is
working with Excel for a period.
We don't have access to a later version of Excel. If still using XL97
they should reduce the size of the worksheets (spread over
multiple sheets). In a workbook, the total of all of the formulas in
the workbook must refer to
less than 16,375 unique cells in any worksheet in any other closed
workbook.
Opening 2nd/3rd instance of Excel is less restrictive with memory
(64MB max per instance) than
their current practice of opening a second/third file within one Excel
session. The sessions will
work independently of each other. Need to explain this to Excel
power-users. Excel will only use
64MB to process its work. Also in case of out of memory messages when
opening workbooks with
external links (i.e. typical to Finance) they should open the linked
to workbooks before opening
the wanted workbook file. Not sure if this can be done in other
instances.
http://support.microsoft.com/?kbid=167079
http://www.decisionmodels.com/memlimitsc.htm
Example error log:
Application exception occurred:
App: excel.dbg (pid=316)
When: 1/5/2004 @ 14:51:33.812
Exception number: c0000005 (access violation)
FAULT ->30103eed 8b06 mov eax,[esi]
ds:093fcc54=????????
If anyone has any advice (please not "Buy Excel 2003") that would be
great
(e-mail address removed)
Juliet