| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
Hi,
*** I think DCULTX::HAN will be able to help me on this case. Any
additional help would be very appreciated ********
This is Leo from Digital Brazil.
I have three very important customer that are using BAAN IV on top of
Digital Unix 4.0x.
I have 4 main problems/questions ?
1) All three customers are claiming that memory resources are being used by
the BAAN processes/users and not given back to the free list even after
finish their tasks.
It's become more strange when they describe that even after the
stop of the entire BAAN product the memory is not made completely available to
the free list.
The only way to make the free list increase again is to reboot
the Operating System.
They have scheduled reboots during the week only to avoid this
memory bottleneck.
As you can see it is not a good solution on a production environment.
I could verify that it is really happening in all these three
environments.
It is generating very serious performance problems.
It seems to be a Digital Unix/BAAN problem. I have heard that HP had
the same problem but they have built a "patch" to fix this problem.
It is our main and critical problem. We don't have a position to give
to the customer. How can them admit that after stopping the BAAN product the
memory is not made available to the free list. They cannot working using
reboots as an workaround to that.
Does anybody has any suggestion or even a tip in order to solve this
problem ?
2) Named Pipes x Sockets :
*****As you can see on 8203.* notes ****************
At the three customer I have changed the row on file $BSE/lib/ipc_info
from :
bisam s 307 370 p ${BSE}/bin/bisam_svr6.1
to:
bisam s 307 370 s ${BSE}/bin/bisam_svr6.1
I did the same on the Oracle line of one customer because he is using
Oracle instead of BAAN.
The overall performance became better.
I have checked and it doesn't happens on HP and IBM platforms.
Why our behavior in terms of using either named pipes or sockets is
so different from our main competitors ?
I have verified that when I change the kernel parameter
fifo_do_adaptive from 1 to 0 the results become much better. It seems to have
a similar effect comparing to the socket utilization on the ipc_info file.
What really fifo_do_adaptive does ?
What does exactly fifo_rbolts_tot, fifo_rbolts_deliv and
fifo_bolts_force parameters mean ? They seem to be really afected by
changing fifo_do_dapative from 1 to 0.
Could anybody explain why it happens ?
3) tbase_param
I have verified on all three customers that when the buffers parameters
on tbase_params is set to 1500 and the high_water_mark is 75% of this value
(as suggested) the BAAN simply stopping responding. When I increase the buffer
parameter to more than 2000 and restart the BAAN the problem does not occur
anymore.
Have anybody ever seen a problem like that before ?
4) We have just three customer on the Brazilian market that are really using
BAAN platform. We are working on 2 more new opportunities. Because of
all that I have mentioned before we are not on a comfortable position. The
customers are talking to each other and sometimes with BAAN and are assuming
that there are performance problems on BAAN applications on top of Digital
Unix platforms. It is becoming a very big problem to us in order to sell
on new customers and even to maintain the installed base satisafaction.
There is right now a "mind share" in the market place that is to choose
Digital Unix + BAAN platform is not a very good and safe action to do.
Could you please tell me about the performance satisfaction of the
customers that you have using Digital Unix + BAAN.
BAAN Brazil is much smaller than Digital and they really don't know
how to deal with these problems. They can always show other customers
much more happy using HP-UX and IBM-AIX.
Please, I really need some help.
Thanks in advance.
Best regards,
Leo
Digital Technical Support
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 10032.1 | KITCHE::schott | Eric R. Schott USG Product Management | Tue Jun 03 1997 14:12 | 23 | |
Hi You don't include enough data for us to speculate on #1. How are you measuring memory? By free memory size with vmstat? This is a bad way to measure resources... Suggestion: I think you should work with the Baan experts, or at least provide the data to support your analysis. On #2, I think you should file a IPMT/CLD...what went on in the notes file does not constitute a bug report, much less a fix/patch. I think you have a bug, but until you report it, I can't guess when it might get fixed... Do include sys_check output for the system On #3, you need a Baan expert... On #4, you need a Baan expert | |||||
| 10032.2 | BANN experts + Digital Unix experts | VAXRIO::LEO | Tue Jun 03 1997 17:42 | 94 | |
Hi Eric,
Thank you for your very quick answer.
>Hi
> You don't include enough data for us to speculate on
>#1. How are you measuring memory? By free memory size with vmstat?
>This is a bad way to measure resources...
I am measuring memory using Performance Manager, vmstat -s, vmstat -M,
dbx, kdbx,monitor,ps and other Digital Unix tools. I have used also the
Larry Woodman's hints that I have collected at the last Unix Symposium.
I really didn't know that vmstat was not a good way to measure memory
resources.
What is in your opinion the best way to measure memory resources ?
It could help me in order to obtain more specific piece of info ...
> Suggestion: I think you should work with the Baan experts, or
>at least provide the data to support your analysis.
I sent mail messages to Ruud Platenkamp ([email protected]), Lee Mari
(EPS::MARI) and Han (DCULTX::HAN). As you did, they also gave me a lot of
support on the problem described on 8203.0.
I have provided the data to BAAN local support as well.
So far I didn't get any answer.
>On #2, I think you should file a IPMT/CLD...what went on in the
>notes file does not constitute a bug report, much less a fix/patch.
>I think you have a bug, but until you report it, I can't guess when
>it might get fixed...
My local CSC support is filing a IPMT/CLD right now.
>Do include sys_check output for the system
I have already executed the sys_check script at the customer site.
As you know the result is a big html file. If someone wants to
see it to get more details about the customer environment please feel
free to contact me.
>On #3, you need a Baan expert...
As I said before these are the people that I know, within Digital, that
have BAAN expertise (or at least access to BAAN experts) :
Ruud Platenkamp (and The Netherlands BAAN team)
Han
Lee Mari
Do you have any additional pointer/contact ? I would really appreciate.
>On #4, you need a Baan expert
As I said before these are the people that I know, within Digital, that
have BAAN expertise (or at leasr access to BAAN experts) :
Ruud Platenkamp ( and the Netherlands BAAN team)
Han
Lee Mari
Do you have any additional pointer/contact ? I would really appreciate.
Bottom line, I am sure that these BAAN performance problems will not be
solved only by Digital Unix engineers. On the other hand I am sure that
BAAN engineers/experts will not be able to solve all this question by
their own.
So what I am trying to do is to link people that know Digital Unix and
BAAN in order to make an effort to solve or better understand these
performance problems.
I am using this Notes conference because I didn't find any other one
that could be related to this specific problem.
Once more thank you very much.
Best regards,
Leo
Digital Technical Support
Brazil
| |||||
| 10032.3 | UTROP1::utoras-198-48-105.uto.dec.com::PILMEYER | Tue Jun 03 1997 17:53 | 15 | ||
Leo, Ruud Platenkamp doesn't work for DIGITAL any more. He's now a Baan employee again. I'd like to stay informed of the IPMT case. This may not be the only problem in this area. We are working these issues, but there are more pressing matters to work on at the moment. I think you need to work these issues through Lee Mari's group who will most likely involve me. There's no need to post this in a public conference. Han Pilmeyer Software Partners Engineering @ Baan | |||||
| 10032.4 | VAXRIO::LEO | Tue Jun 03 1997 18:22 | 11 | ||
Han,
Thank you very much.
I will keep you updated as much as I can.
Best regards,
Leo
Digital Technical Support
Brazil
| |||||
| 10032.5 | fifo_do_adaptive | NNTPD::"[email protected]" | Dave Cherkus | Wed Jun 04 1997 09:49 | 12 |
The adaptive fifo feature was added to aid programs that are using fifos for high bandwidth. Several important benchmarks do this as well as many production codes such as shell pipes. Apparently your code is using fifos for low latency messaging. In this case the fifo_do_adaptive feature is causing problems. If this is indeed the dominant activity on your system you should turn it off. When the feature is off you will see more context switching but better latency. Dave [Posted by WWW Notes gateway] | |||||
| 10032.6 | VAXRIO::LEO | Wed Jun 04 1997 19:23 | 5 | ||
Hi Dave,
Thank you !
Leo
| |||||