能否提供一些使用Grid K2进行Petrel特定调整的帮助

嗨，Serdar：
如果CPU不是限制，我首先要看的是大文件，数据是如何传递的。
也许你的磁盘I / O是限制因素？
另外，你在为客户使用什么 - 某种PC，瘦客户端等？
在大型框架成为瓶颈的情况下也是如此。



以下为原文

Hi, Serdar:
The first thing I would look at if the CPU is not the limitation is with large files, how your data are being delivered. Is perhaps your disk I/O the limiting factor? Also, what are you using for the client -- some sort of PC, thin client, etc.? This can also in cases of large frames be a bottleneck.

托比亚斯提出了一个很好的观点，特别是考虑到它适用于较小的文件。
Serdar，你说网络很好，但是你将存储与其他网络流量分开，你能看到任何问题吗？
在任何一点使用巨型帧？
您是否可以将大文件带到XD部署旁边以查看是否有任何改变？



以下为原文

Tobias makes a great point, especially given that it works well with smaller files.  Serdar, you said networking is fine but are you separating storage from other network traffic and can you see any issues there?  Using jumbo frames at any point?  Can you bring the large files adjacent to the XD deployment to see if that changes anything?

是的，存储连接 - 除了存储的实现，包括磁盘RPM，SATA与SAS，RAID配置类型，主轴数量，连接类型（iSCSI，HBA，NFS等） - 可以
一切都有所不同，当然还有多少虚拟机在同一个SR上共享，以及SR是如何从LUN中划分出来的。
凭借巨型帧我老实说从来没有见过超过10-15％的改进，但如果它可以实现，它肯定是一个奖金。
如上所述，将存储网络与其他存储网络隔离非常重要。



以下为原文

Yes, the storage connection -- in addition to the implementation of the of storage, including disk RPMs, SATA vs. SAS, type of RAID configuration, number of spindles, connection type (iSCSI, HBA, NFS, etc.) -- can all make a difference, as well as of course how many VMs are shared on the same SR and how the SR is carved out of a LUN. With jumbo frames I honestly have never seen more than perhaps a 10 - 15% improvement, but if it can be implemented, it's certainly a bonus. As Like mentioned above, isolating the storage network from all others is very important.

嗨Serdar，
如果您仍然遇到困难，请告诉我们。
在过去的几年里，我们在使用XenDesktop为SLB Petrel部署NVIDIA GRID方面取得了巨大成功。
即使使用~2TB数据集（一旦我将它从便携式USB驱动器上以大约25MB / s的速度运行......）。
不久将会有一个案例研究，说明我们采取了哪些措施来使HDX3DPro顺利运行。
同时这里有一个片段：
http://360is.com/performance.html
地质学家很高兴。
正如托比亚斯所说，可能有很多事情可能导致业绩不佳，我们会处理所有问题。
N.



以下为原文

Hi Serdar,

If you are still experiencing difficulty let us know. We've had great success in deploying NVIDIA GRID with XenDesktop for SLB Petrel over the past couple of years. Even with a ~2TB data-set (once I'd got it off the portable USB drive at about 25MB/s...). There will be a case study shortly on what we did to get it all running smoothly with HDX3DPro. Meanwhile there's a snippet here:

http://360is.com/performance.html

The geologists were delighted.
As Tobias says there can be so many things that might be the cause of poor performance, and we deal with them all.

N.

我讨厌这样说，但我们仍然使用直接I / O（使用开放式iSCSI）来满足我们更关键的（速度至关重要）存储需求。
通过完全绕过SR机制，您可以获得高达6倍的性能。
我还没有在Creedence Alpha平台上对此进行测试，但怀疑Creedence中所做的所有改进，我可以获得一些令人印象深刻的数据 - 可能仍然不如裸机或品牌X，但仍然更好
“股票”系统。
虽然我（显然）无法使存储Xenmotion与opne iSCSI机制一起工作，但Xenmotion本身也是如此。
也许这甚至不相关，因为至少对于绑定到vGPU的VM而言，Xenmotion目前还无法正常运行。
附：
嘿，360：爱你的网站，并在各处穿插着诙谐的评论！



以下为原文

I hate to say it, but we still use direct I/O (using open iSCSI) for our more critical (where speed is essential) storage needs. By bypassing the SR mechanism altogether you can get up to 6x the performance. I have not tested this yet on a Creedence Alpha platform, but suspect with all the improvements that have been made in Creedence that I could get some impressive stats -- maybe still not as good as bare metal or Brand X, but still way better that the "stock" system. While I have not been able to (obviously) get storage Xenmotion to work with the opne iSCSI mechanism, Xenmotion itself does. Maybe that isn't even relevant since at least for a VM tied to a vGPU, Xenmotion is not currently functional, anyway.

P.S. Hey, 360: Love your Web site and tongue-in-cheek comments interspersed all over the place!

嗨托比亚斯，
自2006年左右以来，我们一直在与XenServer合作，因此我们意识到追求性能的漫长旅程。
存储性能，特别是共享存储性能需要工作。
我真正想要看到的是Infiniband / SRP存储，所以我们可以完全转储TCP / IP ......也许客户会付钱给我们工作！
为了它的价值，我们现在已经完成了一些NVIDIA / vGPU项目，只要客户在硬件上完成了他的作业或者允许我们指定所有项目，他们在性能和稳定性方面都表现得非常好。
很高兴你喜欢这个新网站，它仍在进行中！



以下为原文

Hi Tobias,

We've been working with XenServer since about 2006 so are aware of the long journey those in search of performance have taken. Storage performance, particularly shared storage performance needs work. What I really want to see is Infiniband/SRP for storage so we can dump TCP/IP entirely... Maybe a client will pay us to work on it!

For what its worth, we've done a few NVIDIA/vGPU projects now and they have worked pretty well in terms of both performance and stability so long as the client has done his homework on hardware or allows us to specify it all.
Glad you like the new web site, it is still a work in progress!

嗨，
我公司是加纳的系统集成商。
我们刚刚为一家小型石油服务公司完成了XD解决方案的部署。
然而，Petrel对于大文件运行严重。
我们的设置包括HP DL380z G8服务器，XenServer 6.2.2，4x Grid K2 GPU（直通模式），Windows 7 SP1 64位，每个VM 8个物理CPU核心，每个VM 64 GB RAM，EMC SAN（我们记录
在VM之间传输文件时，130Mbyte / s），XD 7.5和VM上的NVIDIA驱动程序。
由于Petrel性能不佳，我们决定将虚拟机管理程序更改为VMware，以防出现问题，但性能问题仍然存在。
当地办事处斯伦贝谢的工程师（顺便说一下他们并不热衷于我们的'虚拟化'方法）刚刚告诉我们，Petrel 2014不支持Grid K2。他们要求我们使用Quadro K5000或K6000。
我们现在已经订购了两张K6000卡，目的是更换Grid K2卡，但不知怎的，我觉得问题可能是别的。
我很感激有关此事的任何建议。
费利克斯



以下为原文

Hi,

My company is a systems integrator in Ghana. We have just completed the deployment of a XD solution for a small oil services company. However Petrel runs badly for large files.

Our setup consists of HP DL380z G8 Server, XenServer 6.2.2, 4x Grid K2 GPUs (in pass-through mode), Windows 7 SP1 64-bit, 8 physical CPU cores per VM, 64GB RAM per VM, EMC SAN (we record 130Mbyte/s when transferring files between VMs), XD 7.5, and NVIDIA drivers on the VMs.

As a result of the bad Petrel performance, we decided to change the hypervisor to VMware in case that was the problem however the performance issue persists.

Local office Schlumberger engineers (by the way they are not enthused with our 'virtualization' approach) have just communicated to us that Grid K2 is not supported by Petrel 2014. They have requested we use Quadro K5000 or K6000. We have now placed order for two K6000 cards with the intention of replacing the Grid K2 cards, but somehow I get the feeling the problem could be something else.

I would appreciate any suggestions on the matter.

Felix

我怀疑问题出在K2卡上，特别是如果您使用的是Passrel模式，Petrel可以访问所有GPU内存。
使用GRID的海燕是一项非常新的技术，因此我可以理解斯伦贝谢人对此感到紧张，他们有更多的Quadro（也是直通）网站。
仅从所提供的信息中提出有用的建议，与具有类似存储/网络/ CPU的物理工作站相比，性能有多糟糕？
我们说的慢2倍，慢10倍，更多？



以下为原文

I doubt the problem is with the K2 cards, especially if you are using pass-through mode where Petrel can access all the GPU memory. Petrel with GRID is quite a new technology, so I can understand the Schlumberger guys being nervous about it, they have a lot more Quadro (also pass-through) sites.

It is hard to make helpful suggestions from just the information supplied, how bad is the performance versus a physical workstation with similar storage/network/CPU?

Are we talking 2x slower, 10x slower, more?

嗨threesixty，
感谢您的回答。
我和Felix在同一个项目上工作，我们从配有NVIDIA Quadro卡的笔记本电脑上运行相同的数据，并且加载数据的速度提高了10倍。
另外我想提一下，Seismic Data（4GB）正在发生这种情况。
我们拥有一个良好的网络存储及其专用的vlan。
我们也试过从本地驱动器运行它没有任何区别。
我们在这里失踪了什么？
ELOM



以下为原文

Hi threesixty,

Thanks for your answer.

I'm working on the same project with Felix and we run the same data from a laptop that has an NVIDIA Quadro card and it loaded the data about 10x faster. Also I would like to mention that this is happening for Seismic Data (4GB). We have a good network storage with its dedicated vlan. And we also tried running it from local drives witch didn't make any difference.

What are we missing here?

Elom

同样在客户端，我们在HP EliteDesk 800系列（I5 Cpu，4Gb ram）上运行Citrix Receiver，连接到30英寸屏幕，分辨率为2560 x 1600。
对于VM的成像技术，我们使用机器创建服务（MCS）。



以下为原文

Also at the client side we are running Citrix Receiver on an HP EliteDesk 800 Series (I5 Cpu, 4Gb ram) connected to a 30" screen at a resolution of 2560 x 1600.

For the imaging technology of the VMs we use Machine Creation Service (MCS).

各个实现的IOPS是多少？
存储结构可能会引入一个瓶颈，表现为数据加载速度缓慢。



以下为原文

What are the IOPS for the respective implementations?

It's possible that the storage fabric is introducing a bottleneck that manifests as slow loading of data.

嗨，杰森，
感谢您的答复。
我检查了存储上的IOPS，并附上了下面的图像。
Hypervisor通过NFS访问存储，并且能够处理高于1000 IO / s的峰值。
文件系统本身也处理高于400 IO / s的峰值。
网络吞吐量也处理超过22000个数据包/秒。
存储是使用Raid 5的带有Sas驱动器（25 x 600 GB，10K RPM）的VNXe 3200;
巨型帧被禁用。
请注意，从存储中复制文件时，Windows记录的速度最高可达130MB / s。
你认为这还不够吗？
我们该怎么做才能改善？
NFS吞吐量：
网络吞吐量：
文件系统吞吐量：



以下为原文

Hi Jason,

Thanks for your response.

I checked the IOPS on the storage and I attached the images below. The Hypervisor accesses the storage through NFS and it is able to handle peaks above 1000 IO/s. The File System itself also handles peaks above 400 IO/s. The network throughput is also handling more than 22000 Packets/s.

The Storage is a VNXe 3200 with Sas drives (25 x 600 GB, 10K RPM) using Raid 5; Jumbo Frames Disabled.

Note that when copying files from the storage, windows records speeds up to 130MB/s.

Do you think it is not enough? What should we do to improve?

NFS Throughput:


Network Throughput:


File System Throughput:

这些结果来自VM吗？
这是一篇很好的论文，关于我们在VM中看到的作为潜在瓶颈的内容，特别是在访问大量数据时。
http://www.atlantiscomputing.com/downloads/Windows_7_IOPS_for_VDI_a_Deep_Dive_1_0.pdf



以下为原文

Are those results from in the VM?


This is a good paper on what we'd be looking at in the VM as a potential bottleneck, especially when it comes to accessing large amounts of data.

http://www.atlantiscomputing.com/downloads/Windows_7_IOPS_for_VDI_a_Deep_Dive_1_0.pdf

嗨，
我一直在研究类似的设置，但使用VMware直接连接GPU。
我们的配置4：1将VM整合到物理​​服务器
每个VM 6个核心@ 3Ghz Per Core
每个虚拟机48GB内存
每个VM专用的GRID K2核心
存储在本地FusionIO IOscale2 SSD上
我们还将它配置为通过vSwitch为每个10GbE适配器配备两个VM。
用途，ESXi 5.5U1
VMware Horizo​​n 6.0.0
APEX 2800由Teradici卸载卡以将PCoIP会话卸载到硬件
我们将虚拟机上的Petrel 2013.7与10GbE上相同存储的T7610工作站进行了基准测试...
20GB立方体（未压缩）ZGY的地震预取采取：
T7610的84.3秒大约235MB / s
虚拟机的92.5秒大约225MB / s
我们没有测试高于20GB的数据集。
这是基于我们的VMDK坐在FusionIO IOscale2 1.6TB卡和10GbE到存储。
对于客户，我们在1GbE Base-T连接上使用了Dell Wyse P45 Zero Client。
所有驱动程序都是最新版本，这是在Windows 7上。
存储是NetApp。
我们还在Petrel 2013.7中测试了压缩35GB ZGY @ 45dB的地震压缩，结果如下：
T7610 Spec  -  16核心@ 3.4Ghz，192GB内存，K4000：文件创建时间281s CPU核心最大输出
虚拟工作站 -  6核@ 3Ghz，48GB内存，GRID K2：文件创建时间663s CPU核心最大输出
我希望这能为您提供一些预期的基准数据，我很想知道XenServer和HDX的表现如何。
没有进行调整以获得这些数据，只是VMware Horizo​​n的标准VMware现成配置。
我会说，Petrel没有经过认证可以在虚拟环境中运行，因此获得Schlumberger的支持最多只能在尽力而为的基础上进行。
如果您想更多地谈谈我们所做的工作，请给我发一封包含您电子邮件地址的私信。
谢谢
Ĵ



以下为原文

Hi,

I've been working on a similar setup but using VMware with direct attached GPU's.

Our configuration 4:1 consolidation of VM's to Physical servers

6-Cores per VM @ 3Ghz Per Core
48GB Memory Per VM
Dedicated GRID K2 Core per VM
Storage on a local FusionIO IOscale2 SSD

We also have it configured to have two VM's per 10GbE adaptor through a vSwitch.

Uses, ESXi 5.5U1
VMware Horizon 6.0.0
APEX 2800 Offload card by Teradici to offload PCoIP sessions to hardware

We benchmarked Petrel 2013.7 on the virtual machines against a T7610 Workstation on the same storage accross 10GbE...

Seismic Prefetch for a 20GB Cube (Uncompressed) ZGY took:

84.3 Seconds for the T7610 Approx 235MB/s
92.5 Seconds for the Virtual Machine  Approx 225MB/s

We didn't test data sets higher than 20GB.

This is based on our VMDK's sitting on a FusionIO IOscale2 1.6TB card and 10GbE to the Storage.

For the clients we used Dell Wyse P45 Zero Clients on a 1GbE Base-T connection.

All drivers were at their latest versions and this was on Windows 7.

Storage was NetApp.

We also tested seismic compression in Petrel 2013.7 compressing 35GB of ZGY @ 45dB with the following results:

T7610 Spec - 16 Cores @ 3.4Ghz, 192GB Memory, K4000: File Creation Time 281s CPU Cores Maxed Out
Virtual Workstation - 6 Cores @ 3Ghz, 48GB Memory, GRID K2: File Creation Time 663s CPU Cores Maxed Out

I hope this gives you some baseline figures on what to expect, I'd be interested to know how XenServer and HDX perform in comparison.

There was no tweaking done to obtain these figures, just standard VMware off the shelf configuration for VMware Horizon.

I'll say this, Petrel is not certified to run in a virtual environment therefore getting support from Schlumberger would at best be on a best effort basis.

If you'd like to talk more around the work we've done, send me a private message with your e-mail address.

Thanks
J

你好埃洛姆，
您是否使用“具有硬盘溢出的设备RAM中的缓存”来测试PVS而不是MCS？
PVS包含在XenDesktop Enterprise / Platinum中，可与XenServer和vSphere（v5.5更新1）配合使用。
您可以在此博客系列中阅读有关新缓存模式的更多信息：
http://blogs.citrix.com/2014/04/18/turbo-charging-your-iops-with-the-new-pvs-cache-in-ram-with-disk-overflow-feature-part-one/
看到你会得到的结果会很有趣。



以下为原文

Hello Elom,

Have you tested PVS instead of MCS with "cache in device RAM with hard disk overflow"? PVS is included in XenDesktop Enterprise/Platinum and works well with both XenServer and vSphere (v5.5 update 1).

You can read more about the new caching mode in this blog series:

http://blogs.citrix.com/2014/04/18/turbo-charging-your-iops-with-the-new-pvs-cache-in-ram-with-disk-overflow-feature-part-one/


It would be interesting to see the results you would get.