 | |
Performance puzzle on Windows server
comp.databases.btrieve comp.databases.btrieve
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: Performance puzzle on Windows server -
11-05-2003
, 12:34 PM
|
"Leonard" <lharvey (AT) austin (DOT) rr.com> skrev i melding news:iqaeqvce02c8mqql018f8sod420unlqvio (AT) 4ax (DOT) com... If it is slow to connect check name resolution times. I can't see that it's this, either. The application is running locally (reading data from a network share on the same server it runs on). That just does not make sense to do. It also falls under the not supported configuration. Why not point it to a local drive (or if the data is on a data volume, reasign the data volume to the appropriate drive letter). It's just to get closer to the issue. The real problem is of course that the workstations experience the performance issues. I found that the problem is the same running just locally on the server, which I thought would be easier to find out of. Is it really not a supported configuration, running off a "local" network share? If it is slow to run, yes check the hardware, but probably more importantly check routing. Now I've even tried with a new network adapter, with the same results. If it is server local it could be the network adapter, but not likely. New adapter may or may not change routing, but server local is not likely to have routing issues either. No, the new adapter did not make any difference. Is the address it connecting to routed through the public side of an internet router? I've tried to disconnect the server entirely from the rest of the network. And it has no effect on the performance, unfortunately. Any extra (or slow) hops on tracerte? Nope. I cannot think of anything else to check/adjust! Going back to the original post, may just want to configure the application to run local (local physical drive) instead of UNC. UNC can force requests to go through the network layer That would solve the problem for running it on the server, but not on the workstations. My assumption was that whether the .btr files was placed on a network share or on a physical disk, the data would still be transferred throug tcpip on port 1583. So the difference between these two scenarios would only be name resolution at the file opening. But perhaps tcpip/1583 is only used with the SQL interface? We only use the Btrieve interface. Does the Btrieve interface transfer the data through the Windows network? |
Gordon Bos
Q-RY Solutions
+31-(0)15-2564035
http://www.q-ry.nl/
#12
| ||||
| ||||
|
|
Wouldn't you want "P.SQL tx log volume" to be RAID 0 ? |
which is lost due to disk failure because the actual updates have
not been applied to the database is more trouble that it's worth!
(IMHO)
Quote:
|
Your solution / idea seems very costly. |
Quote:
|
I've played with similar ideas, but stuck with living dangerously: RAID 5 for data that really matters and RAID 0 for temp stuff, including P.SQL transactional log. |
Quote:
Glad to know I'm not the only freak around here though  |
Guy, doing RAID 1 since 1987!
-- --------------------------------------------------------------------
Guy Dawson I.T. Manager Crossflight Ltd
gnues (AT) crossflight (DOT) co.uk
#13
| ||||
| ||||
|
|
"Leonard" <lharvey (AT) austin (DOT) rr.com> skrev i melding news:iqaeqvce02c8mqql018f8sod420unlqvio (AT) 4ax (DOT) com... If it is slow to connect check name resolution times. I can't see that it's this, either. The application is running locally (reading data from a network share on the same server it runs on). That just does not make sense to do. It also falls under the not supported configuration. Why not point it to a local drive (or if the data is on a data volume, reasign the data volume to the appropriate drive letter). It's just to get closer to the issue. The real problem is of course that the workstations experience the performance issues. I found that the problem is the same running just locally on the server, which I thought would be easier to find out of. Is it really not a supported configuration, running off a "local" network share? |
because of the overhead involved (too slow... at least in comparison
to local) but otherwise functional.
May just be the quantity of data.
What does the Pervasive Monitor utility show for requests processed?
Unfortunately it is on the communication screen so it only shows
remote requests but it can be enlightening especially combined with
other information like cache hits vs. misses and record sizes which
dictate how much data is passed in a request.
Quote:
|
If it is slow to run, yes check the hardware, but probably more importantly check routing. Now I've even tried with a new network adapter, with the same results. If it is server local it could be the network adapter, but not likely. New adapter may or may not change routing, but server local is not likely to have routing issues either. No, the new adapter did not make any difference. |
can make a tremendous performance difference. I have seen 3x just by
changing adapters and the application was not file IO light either
with lots of table scans (non-cacheable) and bulk updates.
Either way it should be going through the loopback adapter (unless the
drive is mapped via the actual IP address) taking the NIC and drivers
themselves out of the picture. Is there any additional network
software installed like monitoring or firewalling software?
Quote:
|
Is the address it connecting to routed through the public side of an internet router? I've tried to disconnect the server entirely from the rest of the network. And it has no effect on the performance, unfortunately. Any extra (or slow) hops on tracerte? Nope. I cannot think of anything else to check/adjust! Going back to the original post, may just want to configure the application to run local (local physical drive) instead of UNC. UNC can force requests to go through the network layer That would solve the problem for running it on the server, but not on the workstations. My assumption was that whether the .btr files was placed on a network share or on a physical disk, the data would still be transferred throug tcpip on port 1583. |
relational engine.
Establishing a session a named pipe call happens over Netbios port 139
just like MS SQL does to exchange some handshake information.
There is also the remote chance you might be using Pervasive IDS which
is port 2441. Great for slow WAN links but lots of overhead compared
to a fast network.
Quote:
|
So the difference between these two scenarios would only be name resolution at the file opening. But perhaps tcpip/1583 is only used with the SQL interface? We only use the Btrieve interface. Does the Btrieve interface transfer the data through the Windows network? |
Leonard
#14
| |||
| |||
|
|
We had similar problems. We could not figure out why our app was so slow. It turned out to be the RAID5 on the server. We got info that database applications should NOT run on RAID5. Try inserting an ordinary IDE disk and compare. |
no performance
issues reading/writing directly to disk. Only when the BTR files are placed
on the "local"
network share things move slowly.
--
Sindre
#15
| ||||
| ||||
|
|
May just be the quantity of data. What does the Pervasive Monitor utility show for requests processed? Unfortunately it is on the communication screen so it only shows remote requests but it can be enlightening especially combined with other information like cache hits vs. misses and record sizes which dictate how much data is passed in a request. |
while,
not much is read from disk, as is expected.
Quote:
|
No, the new adapter did not make any difference. A new adapter will not change any routing. Different NIC / drivers can make a tremendous performance difference. I have seen 3x just by changing adapters and the application was not file IO light either with lots of table scans (non-cacheable) and bulk updates. Either way it should be going through the loopback adapter (unless the drive is mapped via the actual IP address) taking the NIC and drivers themselves out of the picture. Is there any additional network software installed like monitoring or firewalling software? |
operations are slow. In these cases, data are transported through the
network
adapter.
When the drive is mapped with 127.0.0.1, the performance is just like as if
it's run directly from physical disk. Which makes sense, as this probably
goes
through the loopback interface.
Quote:
|
For transactional requests it goes to port 3351 actually. 1583 is the relational engine. Establishing a session a named pipe call happens over Netbios port 139 just like MS SQL does to exchange some handshake information. There is also the remote chance you might be using Pervasive IDS which is port 2441. Great for slow WAN links but lots of overhead compared to a fast network. |
Quote:
|
But perhaps tcpip/1583 is only used with the SQL interface? We only use the Btrieve interface. Does the Btrieve interface transfer the data through the Windows network? Standard Winsock calls. |
Well, the next things to try (in order):
* Try a new network switch
* Reinstall the tcpip protocol on the server
* Reinstall the server
Thank you for all the help.
--
Sindre
#16
| |||
| |||
|
|
When the drive is mapped with the name or IP address of the server, the db operations are slow. In these cases, data are transported through the network adapter. When the drive is mapped with 127.0.0.1, the performance is just like as if it's run directly from physical disk. Which makes sense, as this probably goes through the loopback interface. ------- Well, the next things to try (in order): * Try a new network switch * Reinstall the tcpip protocol on the server * Reinstall the server Thank you for all the help. |
Gordon Bos
Q-RY Solutions
+31-(0)15-2564035
http://www.q-ry.nl/
#17
| |||
| |||
|
|
Hold on, hold on..... I missed you saying it only worked okay with the loopback address... Now this may sound silly, but the problem MAY be in your IP address. Obviously you will know the last number should not be 0 and with Windows you don't want any numbers above 250. Now comes the tricky part: I have seen at least one case where a certain IP adress (e.g. 10.0.0.1) seemed to confuse the router. This may have had something to do with IPX also being installed, but in thruth I really don't know. Changing the address did the trick... |
points you mention). But I do know we have other customers with an address
like 10.0.0.1.
Thank you.
--
Sindre
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.