[Paraview] memory load on client when running on server

Thu Jun 19 17:10:25 EDT 2014

The server has about 16GB of ram, while the client has 8GB. I am loading
only one array and I am starting the server with a simple 'pvserver' then I
establish the connection manually from PV which I start simply calling
'paraview'.

--enable-bt is not a valid option but dmesg does show a segfault:
at-spi-bus-laun[17239]:
segfault at 968 ip 0000003e4e425321 sp 00007fff9770a040 error 4 in
libX11.so.6.3.0
I don't think that this can be the problem though because the same
excessive memory load happens on the client mac with no crash and a
different version of X (XQuartz).

in the case of remote rendering I should see a black window coming from
pvserver where the dataset should be displayed, right? well I see the
window but nothing gets rendered on it... if remote rendering is disabled
do I still see the window?
j

On Thu, Jun 19, 2014 at 4:43 PM, Burlen Loring <burlen.loring at gmail.com>
wrote:

>  questions:
> So how much ram is on this system?
> How many arrays are you loading? If memory is an issue you may get by by
> loading only one (or fewer) of them.
> What command line are you using to start the server?
>
> Can you start the client and server with --enable-bt on the respective
> command lines? This should print a stack trace during the crash. If it does
> send it to the list. If PV is killed because its out of memory this may
> have been logged (on linux: dmesg | egrep -i 'killed process').
>
> about your original question: When in client server(not multicore) with
> the server running on a remote system and the client on your desktop, the
> client only has to display images rendered on the server. so very low load
> on the client side. If you're seeing a high load in that case , remote
> rendering is probably disabled, perhaps this is a bug.
>
> multicore would disable remote rendering , according to a recent post on
> the mail list.
>
> mulitcore the client and servers run on the same system and thus the X
> server load could in fact be coming from the server rather than the client.
>
>
> On 06/19/2014 01:26 PM, jean mensa wrote:
>
> it's the crash. The server loads about 8GB of data and then it idles. The
> status bar also shows that the vtkUnstructuredGridReader is loading the
> dataset and it reaches 100% without giving any errors. The problem seems to
> be displaying the data...
>
>
> On Thu, Jun 19, 2014 at 4:17 PM, Burlen Loring <bloring at lbl.gov> wrote:
> >
> > The server seems to load the dataset properly but no image is shown on
> the client.
> >
> > OK, so is this the crash or a new issue? If there's no image how could
> you tell the server loaded the dataset correctly?
> >
> >
> >
> > On 06/19/2014 12:53 PM, jean mensa wrote:
> >
> > same result. I disabled multicore and I was already using 0MB remote
> rendering threshold. I have tried with paraview on both linux and macosx.
> The server seems to load the dataset properly but no image is shown on the
> client.
> >
> >
> >
> > On Thu, Jun 19, 2014 at 3:40 PM, Burlen Loring <bloring at lbl.gov> wrote:
> >>
> >> Ug. you're using the multicore option to start the servers! I believe
> that this forces remote rendering off. That would explain your issues.
> Could you try duisabling the multi core option and start your servers
> manually?
> >>
> >>
> >> On 06/19/2014 12:29 PM, Burlen Loring wrote:
> >>
> >> OK, one possibility is that it may be related to remote rendering
> settings. Under menu Edit->Settings->Render View->Server there is a remote
> render threshold. I always set this to 0 bytes to ensure remote parallel
> rendering. What's yours set to?
> >>
> >> On 06/19/2014 12:18 PM, jean mensa wrote:
> >>
> >> Sorry, I didn't explain it properly. I have already tried to connect to
> a pvserver from a GUI running on the client (without an ssh connection
> then) but it also drains the memory on Xorg. What is the load supposed to
> be on a client-pvserver connection?
> >> Thanks,
> >>
> >>
> >> On Thu, Jun 19, 2014 at 3:08 PM, Burlen Loring <bloring at lbl.gov> wrote:
> >>>
> >>> Jean,
> >>>
> >>> What you describe is expected. X forwarding doesn't work well for
> visualizing large datasets. The point is : don't use X forwarding. The
> links show how to configure the client server connection without X
> forwarding. Make sure that there is no -X on the ssh command line.
> >>>
> >>> Burlen
> >>>
> >>>
> >>> On 06/19/2014 11:46 AM, jean mensa wrote:
> >>>
> >>> When I do that Xorg process on the client drains the memory up until
> it crashes. The connection I think is properly established since it works
> fine for smaller datasets. What should the load on the client be in that
> case?
> >>> j
> >>>
> >>>
> >>> On Thu, Jun 19, 2014 at 2:14 PM, Burlen Loring <bloring at lbl.gov>
> wrote:
> >>>>
> >>>> Yes, this is expected. The OpenGL calls get piped to your local
> system. This includes data like vertices and colors as well. X forwarding
> doesn't give good performance and with large data it may not even be
> feasible.
> >>>>
> >>>> You need to set up client server connection.
> >>>>
> >>>> http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding
> >>>> http://www.paraview.org/Wiki/ParaView:Server_Configuration
> >>>> http://www.paraview.org/Wiki/Setting_up_a_ParaView_Server
> >>>> http://www.paraview.org/Wiki/ParaView_And_Mesa_3D
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 06/19/2014 10:33 AM, jean mensa wrote:
> >>>>
> >>>> Hi all,
> >>>> I have a rather large unstructured pvtu dataset (about 4 million
> points) which I am visualizing on a remote server. I am running the
> paraview GUI (with the multicore option) on the server and I connect to it
> via ssh sharing the X server. In this way I can control the GUI running on
> the serve. I thought that with this configuration I would only receive a
> screenshot of the window and no actual data from paraview but the client
> seems to share at least some of the load of the visualization. Is this the
> expected behaviour? How can I avoid loading data on the client side?
> >>>> Thanks in advance,
> >>>>
> >>>> --
> >>>> Jean A. Mensa
> >>>> Graduate Assistant
> >>>> University of Miami
> >>>> RSMAS - MPO
> >>>> 4600 Rickenbacker Causeway
> >>>> Miami, FL 33149-1098
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Powered by www.kitware.com
> >>>>
> >>>> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >>>>
> >>>> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
> >>>>
> >>>> Follow this link to subscribe/unsubscribe:
> >>>> http://public.kitware.com/mailman/listinfo/paraview
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jean A. Mensa
> >>> Graduate Assistant
> >>> University of Miami
> >>> RSMAS - MPO
> >>> 4600 Rickenbacker Causeway
> >>> Miami, FL 33149-1098
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Jean A. Mensa
> >> Graduate Assistant
> >> University of Miami
> >> RSMAS - MPO
> >> 4600 Rickenbacker Causeway
> >> Miami, FL 33149-1098
> >>
> >>
> >>
> >
> >
> >
> > --
> > Jean A. Mensa
> > Graduate Assistant
> > University of Miami
> > RSMAS - MPO
> > 4600 Rickenbacker Causeway
> > Miami, FL 33149-1098
> >
> >
>
>
>
> --
> Jean A. Mensa
> Graduate Assistant
> University of Miami
> RSMAS - MPO
> 4600 Rickenbacker Causeway
> Miami, FL 33149-1098
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:http://public.kitware.com/mailman/listinfo/paraview
>
>
>

-- 
*Jean A. Mensa*
*Graduate Assistant*
University of Miami
RSMAS - MPO
4600 Rickenbacker Causeway
Miami, FL 33149-1098
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20140619/d6879360/attachment.html>