[Paraview] memory load on client when running on server

Burlen Loring bloring at lbl.gov
Thu Jun 19 17:42:08 EDT 2014


Could you share the dataset? Maybe I can reproduce the issue.

Which version of PV are you using? You're not using the latest(4.1) if 
--enable-bt isn't there.  Upgrading to 4.1 may help...

On 06/19/2014 02:10 PM, jean mensa wrote:
> 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 <mailto: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
>>     <mailto: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
>>     <mailto: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 <mailto: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 <mailto: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 <http://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 bywww.kitware.com  <http://www.kitware.com>
>>
>>     Visit other Kitware open-source projects athttp://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/c09cd860/attachment-0001.html>


More information about the ParaView mailing list