I have written a program in Delphi 7 (includes a ModBus component that uses Indy). On my machine it uses Indy 9 and works fine. It communicates well with other machines via a ModBus protocol. However, when the program is run on a different machine, I get a CPU 90-100% load. Unfortunately this machine is not in my office but "on the other side of the world". How can I find out whether this machine is using Indy 9 or Indy 10? And, further, If it is running Indy 10, could that be the problem or is this very unlikely?
Definitive answer is No
If you compile your program with indy 9, even if using packages, it shall use INDY 9 to run. AFAIK, there's no way to compile the executable using INDY 9 and use INDY 10 at runtime, even if you want, and no way it happen by accident.
To find out whats causing the high CPU load you might try a profiler like AQTime or SamplingProfiler.
That will get you the method(s) that are running most of the time. Then you will be able to find out whats causing the problem.
Alternatively you could add some logging to your application.
To find the root cause you could prepare a test application which will go through a sequence of actions like opening / closing connections. If it asks the user for confirmation ("Continue ? y/n") before proceeding, the user can check the CPU load for every step to detect the critical operation.
Thanks for answers. I do not think this is an Indy issue though. On my Quad CPU PC the CPU load also goes up from 1-2 % to aprox. 25%. This happens if I keep the line open (connected). If I, however, disconnect the ModBus Server after every poll from the ModBus CLient side and let that PC reconnect, the CPU load is always low. WHat is normal? Having the line open all time, or connect and disconnect for every poll? The polling frequency is: in Idle mode : 2000ms, in active mode 500ms.
you need to add logs to ensure you know whats going on.
is it the connection itself that is causing you the issue? or is it the work performed while connected?
Logs will help you narrow this down and you may be able to alter you code to be less processor hungry.
using AQTime or SamplingProfiler as also suggest earlier will help you.
personally i always add logging to every application by default, alot of them require turning on but its there. Once the software it on site you never know what may change and simply turning the logs on can save you alot of time
Related
Environment:
Delphi 2009 client applications (and one Java), running on Windows 2003 server
connecting to InterBase 7.5.1 (another Windows 2003 Server) over dbExpress
The Delphi applications log the time to open the TSQLConnection using the AfterConnect event handler of the TSQLConnection object.
In random intervals, the connect need a three-minutes "extra time". I first suspected it could be a problem with the SQL query, but more detailed logging today showed that it is the SQLConnection.Connect which hangs.
I am not sure if this could be a problem with network, the InterBase server, or the Delphi / dbExpress layer.
Has anybody experienced a similar three-minutes "hang"?
p.s. the Java application does not log connect time so I can not say wheter it is affected by this problem.
This phenomenon appeared in the log files since we started with logging in 2012, but the rate has sharply increased last month. The only environment change has been the addition of new Windows servers (for RDP services, Mail, and Fax) so it could be a network-related problem.
Aside of a possible network problem, the cause of the delay can be that, from time to time, your query triggers a garbage collection in one of the table(s) that it is querying.
I don't know in detail Interbase 7.5 internals, but in my experience (with Firebird), this usually happens when a select is made on a table from which many records have been deleted/updated recently.
This doc at IBExpert.net explains it:
A garbage collection is only performed during a database sweep, database backup or when a SELECT query is made on a table (and not by INSERT, ALTER or DELETE). Whenever Firebird/InterBase® touches a row, such as during a SELECT operation, the versioning engine sweeps out any versions of the row where the transaction number is older than the Oldest Interesting Transaction (OIT). This helps to keep the version history small and manageable and also keeps performance reasonable.
A periodic sweep or backup made at low usage hours, can increase performance and minimize the risk of being hitted by an inconvenient garbage collection. See Sweep interval and automated housekeeping (page 6-20) and Facilitating garbage collection (page 11-19) at the Interbase 7.5 Operations Guide for more info on this.
Please check if hard disk power saving is activated on any disk on mentioned servers. That would explain if you have a delay in first connect and then no delay in following connections. Then, after a while power saving gets activated and the same problem raises again.
Since the rate has increased with the additions of new servers on the network you could have a packet loss and a long timeout to retry. For test that hypothesis you can change the connection timeout to a small value. You also can monitor the network traffic between the servers using wireshark or tcpdump.
Monitoring
To monitor the TCP handshake only you can use:
tcpdump -i eth0 'tcp[13] & 2 = 2
I was given 10 new PCs, all (supposedly) with Windows 7 Pro freshly installed and nothing else done to them.
I have a program, coded in Delphi XE2, using Indy 10 components for the networking. I set the "connect timeout" and "read timeout" properties of my TIdTcpCleint to 500ms, set "resuse socket" to 'o/s dependant'" (I also tried a build with it set to No) and leave "use Nagle" (whatever that is set to True (I also tried with false).
Here's the problem: when I run the same .EXE on these PCs and test the case where I pull the network cable, my debug trace shows the connect attempt / connect timeout happening in the same second or the next second (with a granularity of 1 second) - but on others it is 20 or 21 seconds before I see the conenction timeout.
It would seem some of that the PCs are not totally "fresh install" as claimed, although I see no aps installed. Maybe some one installed somethign then removed it, maybe they tried to tweak performance.
Before I reinstall Windows on 10 PCs, can anyone suggest where to look? Does 20 (or 21) seconds ring a bell with regard to TCP Client connect timeout?
[update] I am attempting to connect directly to a specific IP Address, so I am not sure if #Nikolai suggestion to check DNS is relevant. Sorry for not mentioning this originally.
[upperdate] the program does not attempt to keep the socket open. It connects, sends some data & disconnects - repeatedly, for each new piece of data.
Sadly, this is working as intended. The connect did already timeout. Indy made the determination that the connect would fail in the 500 milliseconds that you asked it to. However, that does not guarantee the function will return.
After the connect times out, Indy spins down the connection to release all of its resources. It does this synchronously. This means that you wind up waiting for the underlying TCP operation to fail. This typically takes 20 seconds.
The solution is to call connect in a thread. Believe it or not, this is what Indy already does to implement the timeout. However, when it times out waiting for the thread, it tries to shut down the connection in the main thread. You need to defer that to a worker thread.
As for why it happens immediately on some systems and in 20 seconds on others, it depends on the precise networking configuration. For example, if IPv6 is enabled, the stack may attempt to use an IPv6-to-IPv4 connection, and that may not report down even if the physical interface is down. Immediate detection of connection impossibility is never guaranteed and you shouldn't rely on it.
I've had same problems with INDY in the past (while using D6, year 1998-2000). I changed the component to IP*Works. At that time it was an external component, but as far as I know it is included in XE2. Ip*Works is a bit hard to understand at the beginning but the way they approach to the communication structure is a lot different.
I think that it would be worth to give it a try.
I am developing Delphi application on Delphi 2010 XE RAD Studio under Windows 7. My application talks on the serial port non-stop. I am using AsyncPro for Delphi 2010. Serial communication and everything else on the computer I develop with works great without any problem. However, when my release version of my application is run on another Windows 7 system, serial communication completely fails. We probed the serial communication itself for an answer and found out that Request to Send (RTS) line is not dropped right after sending all the bytes, whereas on my development computer RTS line is dropped correctly.
Even when I explicitly drop the RTS line to low or false state, RTS line doesn't drop right away but after good 15 milliseconds. Thus, serial communication on my release version is failing.
Am I missing important information about Windows 7 and serial communication issues?
UPDATE: I just found the bug with my Aysncpro 5.0 for Delphi XE. It is weird. When my Delphi XE IDE is open or running, my program is communicating flawlessly. When I shutdown or close my Delphi XE IDE while my program is running, the same program doesn't communicate very well or it times out.
Chime in if you have any idea why it is happening.
Any help will be appreciated.
Thank you,
Sounds like a timer resolution problem to me. I had the same problem trying to write to a USB FTDI driver using an event based timer with timeSetEvent()... When Delphi loads, it changes the timer resolution to less than 20ms, which made my app work fine. When the IDE wasn't running I couldn't get things to work below 20ms +/- 5ms (the default Windows resolution I believe).
To fix the problem, I call timeBeginPeriod(1) in the thread to set the minimum system wide timer resolution.
I believe this affects the resolution of other time based events, because I get better than +/-5ms accuracy on other (non-multimedia timer) wait events in my app when I use timeBeginPeriod().
So, what I'm suggesting is that somewhere in the AsyncPro code it's using some time based event or call back... That would be affected by Delphi's change to the timer resolution when it is loaded. Try calling timeBeginPeriod(1) somewhere in your app when it starts and see if there is a change.
Oh, and don't forget to call timeEndPeriod(1) when your app shuts down.
N#
Last few times I saw random inexplicable crap like I tried everything, and was unable to solve it for months.
I found two different common causes:
ASYNC Professional has some weird glitches that I was unable to solve, so I dropped it, and moved to TComPort.
I found all kinds of strange flow control bugs in USB drivers. I found FTDI chipset USB-to-serial more reliable than others.
The Debug build not having the problem could be two things:
Certain timing changes cause the USB device driver that was failing, not to fail.
You actually have some kind of a thread problem, like a race condition, leading to your ASync Pro components messing up in a way that looks like something's happening to your port, but really it's ASYNC pro.
The easiest thing to do is to try it with a different USB to serial adapter, and if that doesn't solve your problem, I would be tempted to pull out AsyncPro which I have also had many random problems with, and either write your own serial port class, or use TComPort. I have some long experience using a TThread that uses a com port "reader/writer" class and have found this the most reliable way to go, because you can tweak low level elements of the Win32 overlapped-IO calls, directly to meet your needs, and also be sure that you don't have some extra complexity/overhead getting in your way. (AsyncPro's complexity and overhead, are a significant potential source of bugs.)
This has to be a driver problem on the other machine, surely? Hardware flow control works fine on my W7 test box as well, (and Vista development machine). If your Apro has set the DCB correctly, and it sounds like it does because of your 'manual' tests, the driver should work...
15ms for a 'manual' RTS change from user mode is sad, but not at all unusual on Windows - that's why the driver should do it.
Rgds,
Martin
I need to connect to a device on the local network, using a TCP/IP connection.
When I use a TIdTCPClient, all works well, except one thing:
If the connection is not available, it takes about 18-20 seconds before I get a timeout.
The property ConnectTimeout has no effect, no matter what values I set. It always takes the same amount of time before a timeout.
This answer mentions long delay times for a timeout, and I am wondering if that's related to the Indy components?
I have to find out if the connection cannot be established very quickly, let's say within 1 second at most.
Is there a way to do this using Indy, or do I need to use different components / a different approach?
(I'm using the Indy 10 version that shipped with Delphi 2009)
EDIT:
I followed the instructions to upgrade Indy to the latest version in this post.
Still the same, it now consistently takes 22 seconds until TCPClient.Connect returns when there is no connection. ConnectTimeout and/or ReadTimeout seem to have no influence on this.
ConnectTimeout works correctly for 2010 and XE. Perhaps you can update your Indy version to the latest (its free). I have a function that does 'quick check' connects, just to check availability of the device and those timeouts are 5 seconds without problems (in both 2010 and XE).
With a default TCP client connect timeout (not specifically set) and a read timeout of 1 second, using Delphi 2010 and the latest Indy version, a local connection (using localhost as the host name) times out in 1 second. So this is definitely not a Delphi/Indy issue. BTW, this gives me an EIdSocketError ("socket error # 10061 connection refused").
I had the same exact problem. Check out this StackOverflow post.
In short, because Indy threads are blocking, you will need to make a threaded process. Then in the primary application create a timer which will terminate the thread if it has not done what it is supposed to do in the time given.
After I implemented this is worked great.
I have a Delphi (hence 32-bit) CGI app running on a Windows 2008 64-bit server that has 24 Gb RAM with IIS7. The web service runs fine for a few days at a time (sometimes a few weeks) and then suddenly starts reporting "Not enough storage available to process this command."
Now I've seen this before in regular Windows apps and it normally means that the machine ran out of memory. In this instance, the server shows that only 10% of physical RAM is in use. On top of that, TaskManager shows only one instance of the CGI executable, with 14Mb allocated. And once it starts it keeps giving the error, regardless of actual server load. No way is this thing really running out of memory.
So I figured there is probably some maximum memory setting in IIS7 somewhere, but I couldn't find anything of the sort. Restarting the web server makes the problem go away until next time, but is probably not the best strategy.
Any ideas?
It might be an IRPStackSize issue as discussed here. And the particular cause mentioned in that article is not the only one, apparently.
The CGI does not seem to ever unload under IIS7, even though it seems to work under IIS6. This seems to be a problem with the CGI support on IIS7.