python的mmap
㈠ python标准库有哪些
Python标准库的内容涵盖了非常多的功能，主要包括文件、字符串和数字处理，数据结构、网络编程、操作系统用户界面、网页测试、线程以及其它的工具。
具体有，1、文件操作相关的模块，os，os。
path，shutil，errno，stat，glob，fnmatch，tempfile等。
2、字符串和文本处理模块，string，re，difflib和textwrap等。
3、数据结构形式，collections，bisect，array，heapq，queue，struct和weakref等。
4、网络编程与操作系统，SocketServer，socket，selectselectors，threading，multiprocessing，subprocess，mmap，sched，asyncore等。
5、网页测试，urllib，扮态urllib2，配则httplib，ftplib，gopherlib，spider等。
6、解析和处理XML，HTMLParser，ElementTree，XMLParser，XMLWriter，SAX，minidom，expat等。
7、除此之厅卖源外，还包含一些其他方便实用的部分，如BaseHTTPServer，CGIHTTPServer，Cookie，templating，xmlrpclib，formatter，email等。
此外，Python还支持第三方库和框架，有很多实用的框架和工具可以让开发者高效、便捷地完成国家工作。
㈡ 在python中一共有多少个标准库
Python 语言官方的参考手册钟，介绍了与 Python 一同发行的标准库。
文本处理服务
string--- 常见的字符串操作
re--- 正则表达式操作
difflib--- 计算差异的辅助工具
textwrap--- 文本自动换行与填充
unicodedata--- Unicode 数据库
stringprep--- 因特网字符串预备
readline--- GNU readline 接口
rlcompleter--- GNU readline 的补全函数
二进制数据服务
struct--- 将字节串解读为打包的二进制数据
codecs--- 编解码器注册和相关基类
数据类型
datetime--- 基本日期和时间类型
zoneinfo--- IANA 时区支持
calendar--- 日历相关函数
collections--- 容器数据类型
collections.abc--- 容器的抽象基类
heapq--- 堆队列算法
bisect--- 数组二分查找算法
array--- 高效的数值数组
weakref--- 弱引用
types--- 动态类型创建和内置类型名称
--- 浅层 (shallow) 和深层 (deep) 复制操作
pprint--- 数据美化输出
reprlib--- 另一种repr()实现
enum--- 对枚举的支持
graphlib--- 操作类似图的结构的功能
数字和数学模块
numbers--- 数字的抽象基类
math--- 数学函数
cmath--- 关于复数的数学函数
decimal--- 十进制定点和浮点运算
fractions--- 分数
random--- 生成伪随机数
statistics--- 数学统计函数
函数式编程模块
itertools--- 为高效循环而创建迭代器的函数
functools--- 高阶函数和可调用对象上的操作
operator--- 标准运算符替代函数
文件和目录访问
pathlib--- 面向对象的文件系统路径
os.path--- 常用路径操作
fileinput--- 迭代来自多个输入流的行
stat--- 解析stat()结果
filecmp--- 文件及目录的比较
tempfile--- 生成临时文件和目录
glob--- Unix 风格路径名模式扩展
fnmatch--- Unix 文件名模式匹配
linecache--- 随机读写文本行
shutil--- 高阶文件操作
数据持久化
pickle--- Python 对象序列化
reg--- 注册配合pickle模块使用的函数
shelve--- Python 对象持久化
marshal--- 内部 Python 对象序列化
dbm--- Unix "数据库" 接口
sqlite3--- SQLite 数据库 DB-API 2.0 接口模块
数据压缩和存档
zlib--- 与gzip兼容的压缩
gzip--- 对gzip格式的支持
bz2--- 对bzip2压缩算法的支持
lzma--- 用 LZMA 算法压缩
zipfile--- 使用ZIP存档
tarfile--- 读写tar归档文件
文件格式
csv--- CSV 文件读写
configparser--- 配置文件解析器
tomllib--- Parse TOML files
netrc--- netrc 文件处理
plistlib--- 生成与解析 Apple.plist文件
加密服务
hashlib--- 安全哈希与消息摘要
hmac--- 基于密钥的消息验证
secrets--- 生成管理密码的安全随机数
通用操作系统服务
os--- 多种操作系统接口
io--- 处理流的核心工具
time--- 时间的访问和转换
argparse--- 命令行选项、参数和子命令解析器
getopt--- C 风格的命令行选项解析器
logging--- Python 的日志记录工具
logging.config--- 日志记录配置
logging.handlers--- 日志处理程序
getpass--- 便携式密码输入工具
curses--- 终端字符单元显示的处理
curses.textpad--- 用于 curses 程序的文本输入控件
curses.ascii--- 用于 ASCII 字符的工具
curses.panel--- curses 的面板栈扩展
platform--- 获取底层平台的标识数据
errno--- 标准 errno 系统符号
ctypes--- Python 的外部函数库
并发执行
threading--- 基于线程的并行
multiprocessing--- 基于进程的并行
multiprocessing.shared_memory--- Shared memory for direct access across processes
concurrent包
concurrent.futures--- 启动并行任务
subprocess--- 子进程管理
sched--- 事件调度器
queue--- 一个同步的队列类
contextvars--- 上下文变量
_thread--- 底层多线程 API
网络和进程间通信
asyncio--- 异步 I/O
socket--- 底层网络接口
ssl--- 套接字对象的 TLS/SSL 包装器
select--- 等待 I/O 完成
selectors--- 高级 I/O 复用库
signal--- 设置异步事件处理程序
mmap--- 内存映射文件支持
互联网数据处理
email--- 电子邮件与 MIME 处理包
json--- JSON 编码和解码器
mailbox--- 操作多种格式的邮箱
mimetypes--- 映射文件名到 MIME 类型
base64--- Base16, Base32, Base64, Base85 数据编码
binascii--- 二进制和 ASCII 码互转
quopri--- 编码与解码经过 MIME 转码的可打印数据
结构化标记处理工具
html--- 超文本标记语言支持
html.parser--- 简单的 HTML 和 XHTML 解析器
html.entities--- HTML 一般实体的定义
XML处理模块
xml.etree.ElementTree--- ElementTree XML API
xml.dom--- 文档对象模型 API
xml.dom.minidom--- 最小化的 DOM 实现
xml.dom.pulldom--- 支持构建部分 DOM 树
xml.sax--- 支持 SAX2 解析器
xml.sax.handler--- SAX 处理句柄的基类
xml.sax.saxutils--- SAX 工具集
xml.sax.xmlreader--- 用于 XML 解析器的接口
xml.parsers.expat--- 使用 Expat 的快速 XML 解析
互联网协议和支持
webbrowser--- 方便的 Web 浏览器控制工具
wsgiref--- WSGI 工具和参考实现
urllib--- URL 处理模块
urllib.request--- 用于打开 URL 的可扩展库
urllib.response--- urllib 使用的 Response 类
urllib.parse用于解析 URL
urllib.error--- urllib.request 引发的异常类
urllib.robotparser--- robots.txt 语法分析程序
http--- HTTP 模块
http.client--- HTTP 协议客户端
ftplib--- FTP 协议客户端
poplib--- POP3 协议客户端
imaplib--- IMAP4 协议客户端
smtplib--- SMTP 协议客户端
uuid---RFC 4122定义的UUID对象
socketserver--- 用于网络服务器的框架
http.server--- HTTP 服务器
http.cookies--- HTTP状态管理
http.cookiejar—— HTTP 客户端的 Cookie 处理
xmlrpc--- XMLRPC 服务端与客户端模块
xmlrpc.client--- XML-RPC 客户端访问
xmlrpc.server--- 基本 XML-RPC 服务器
ipaddress--- IPv4/IPv6 操作库
多媒体服务
wave--- 读写WAV格式文件
colorsys--- 颜色系统间的转换
国际化
gettext--- 多语种国际化服务
locale--- 国际化服务
程序框架
turtle--- 海龟绘图
cmd--- 支持面向行的命令解释器
shlex—— 简单的词法分析
Tk图形用户界面(GUI)
tkinter—— Tcl/Tk 的 Python 接口
tkinter.colorchooser--- 颜色选择对话框
tkinter.font--- Tkinter 字体封装
Tkinter 对话框
tkinter.messagebox--- Tkinter 消息提示
tkinter.scrolledtext--- 滚动文字控件
tkinter.dnd--- 拖放操作支持
tkinter.ttk--- Tk 风格的控件
tkinter.tix--- TK扩展包
㈢ mmap是什么格式的文件怎么打开
mmap：是MindManager导图默认的官方保存格式，也是使用最多的保存格式。
MindManager作为专业实用性软件，和其他的软件有很好的兼容性，从MindManager的导出格式上就可以看出来，MindManager支持15种导出格式，完全满足用户的所有需求，本教程将主讲MindManager思维导图的导出格式。
MindManager 2019 win版 :点击免费获取MindManager 2019下载地址
MindManager 11 Mac版 :点击免费获取MindManager 下载地址
打开MindManager思维导图软件，制作好导图。点击文件→另存为。在文件另存为对话框内点击保存类型右边的倒置三角，即可打开导图的保存格式列表。
mmap：是MindManager导图默认的官方保存格式，也是使用最多的保存格式。
xmmap、xml：是另一种MindManager导图的保存格式。
mmat、xmmat：是MindManager模板较常用的保存格式。
ppt、pot：是将MindManager导图保存为PPT格式，方便文稿演示。
docx、dotx、doc、dot：是将MindManager导图保存为Word文档，便于存储。
pdf：是将MindManager导图保存为PDF文件，PDF是交互式只读文件，便于查阅。
swf：是将MindManager导图保存为swf格式，便于插入到网页和在Flash浏览器中查看。
jpeg、jpg：是将MindManager导图保存为图片的格式。
以上格式是MindManager最常见的导出格式，其他的格式需要专业的软件才能打开，用户使用的也比较少，在此不作详解。
㈣ 如何用Python一门语言通吃高性能并发，GPU计算和深度学习
第一个就是并发本身所带来的开销即新开处理线程、关闭处理线程、多个处理线程时间片轮转所带来的开销。
实际上对于一些逻辑不那么复杂的场景来说这些开销甚至比真正的处理逻辑部分代码的开销更大。所以我们决定采用基于协程的并发方式，即服务进程只有一个(单cpu)所有的请求数据都由这个服务进程内部来维护，同时服务进程自行调度不同请求的处理顺序，这样避免了传统多线程并发方式新建、销毁以及系统调度处理线程的开销。基于这样的考虑我们选择了基于Tornado框架实现api服务的开发。Tornado的实现非常简洁明了，使用python的生成器作为协程，利用IOLoop实现了调度队列。
第二个问题是数据库的性能，这里说的数据库包括MongoDB和Redis，我这里分开讲。
先讲MongoDB的问题，MongoDB主要存储不同的用户对于验证的不同设置，比如该显示什么样的图片。
一开始每次验证请求都会查询MongoDB，当时我们的MongoDB是纯内存的，同时三台机器组成一个复制集，这样的组合大概能稳定承载八九千的qps，后来随着我们验证量越来越大，这个承载能力逐渐就成为了我们的瓶颈。
为了彻底搞定这个问题，我们提出了最极端的解决方案，干脆直接把数据库中的数据完全缓存到服务进程里定期批量更新，这样查询的开销将大大降低。但是因为我们用的是Python，由于GIL的存在，在8核服务器上会fork出来8个服务进程，进程之间不像线程那么方便，所以我们基于mmap自己写了一套伙伴算法构建了一个跨进程共享缓存。自从这套缓存上线之后，Mongodb的负载几乎变成了零。
说完了MongoDB再说Redis的问题，Redis代码简洁、数据结构丰富、性能强大，唯一的问题是作为一个单进程程序，终究性能是有上限的。
虽然今年Redis发布了官方的集群版本，但是经过我们的测试，认为这套分布式方案的故障恢复时间不够优秀并且运维成本较高。在Redis官方集群方案面世之前，开源世界有不少proxy方案，比如Twtter的TwemProxy和豌豆荚的Codis。这两种方案测试完之后给我们的感觉TwemProxy运维还是比较麻烦，Codis使用起来让人非常心旷神怡，无论是修改配置还是扩容都可以在配置页面上完成，并且性能也还算不错，但无奈当时Codis还有比较严重的BUG只能放弃之。
几乎尝试过各种方案之后，我们还是下决心自己实现一套分布式方案，目的是高度贴合我们的需求并且运维成本要低、扩容要方便、故障切换要快最重要的是数据冗余一定要做好。
基于上面的考虑，我们确定基于客户端的分布式方案，通过zookeeper来同步状态保证高可用。具体来说，我们修改Redis源码，使其向zookeeper注册，客户端由zookeeper上获取Redis服务器集群信息并根据统一的一致性哈希算法来计算数据应该存储在哪台Redis上，并在哈希环的下一台Redis上写入一份冗余数据，当读取原始数据失败时可以立即尝试读取冗余数据而不会造成服务中断。
㈤ 菜鸟关于linux下装应用程序的问题
Linux 操作系统、构建工具和多数语言的编译器可免费获得并可从因特网上下载。为了开始移植，您将需要提供硬件和开发人员：
第 1 步 — 下载所需的开发工具和 Linux 分发版。
第 2 步 — 改用 Linux 开发工具但仍然运行 Solaris。这种方法使得转变更平缓。
第 3 步 — 熟悉 Linux 操作系统但仍旧在 Sun 硬件上运行。
第 4 步 — 把应用程序移到目标 Linux 平台。
第 1 步：下载
以下列出的是所需的编译器、构建工具和相关的在线文档链接：
GCC（GNU Compiler Collection）工具套件包含一个 C 编译器和一个 C++ 编译器
gcc.gnu.org/releases.html
在线文档
gcc.gnu.org/onlinedocs/gcc-2.95.2/gcc_toc.html
Solaris GNU 编译器和 make（gmake）实用程序
www.sunfreeware.com/
在线文档
docs.sun.com/
gnu.org/manual/make-3.79.1/html_mono/make.html
Linux 可从以下 Linux 发行商那里获得。
Caldera www.caldera.com/
Red Hat www.redhat.com/
SuSE www.suse.com/
Turbolinux www.turbolinux.com/
— Linux 的 UltraSPARC 版本
Sun www.sun.com
第 2 步：为 Solaris 上的 Linux 构建您的 C/C++ 应用程序
安装工具 — 先在 Solaris 上安装 GNU 工具。由于 GNU 编译器和 make 实用程序在 Solaris 和 Linux 上都能用，所以使用这些工具来尝试初次构建您的 Linux 应用程序相对较容易。
转换 makefile — 构建您的应用程序时请用 GNU gmake 实用程序，别用 Solaris make 实用程序。根据您的 makefile 中用到的构造，您可能遇到 GNU gmake 实用程序产生的错误消息，因为 GNU gmake 实用程序和 Solaris make 实用程序是有区别的。请用 make 工具文档来帮助找出 makefile 中有问题的地方，然后对 makefile 作出所需的调整。
编译和调试 — 当您通过修改您的 makefile、使之能被 gmake 使用后，把 makefile 中调用 C 编译器的名字 cc 改为 gcc，C++ 编译器的名字 CC 改为 g++。然后编译该应用程序。您在构建中所遇到的错误消息，如果有的话，可被分成两类：命令行选项问题和代码问题。
找出由于 GNU 和 Sun 编译器所接受的命令行选项有所不同而产生的消息。除了几个基本选项（例如“-c”和“-g”），两个编译器能接受的多数选项是不同的。请参阅编译器文档，修改您的 makefile，以适应编译器选项间的区别。
下一步，您可以处理剩下的与代码有关的错误消息和警告。请参阅编译器文档，理解并解决由于编译器之间的差别而产生的问题。
第 3 步：在 Linux 的 Sun UltraSPARC 版本上构建和测试您的应用程序。
如果所移植的应用程序依赖特定的 UltraSPARC 硬件，那么这是移植过程中的重要阶段。Solaris 开发者有机会熟悉 Linux 环境而不必放弃下层的 UltraSPARC 硬件，也不必修改应用程序中特定于硬件的部分。
安装 Linux 环境 — 在 Sun UltraSPARC 上，安装 Linux 和 GNU 实用程序。
编译并调试运行时 API — 因为您在构建您的应用程序时用的是 GNU 实用程序，所以您在这步看到的区别限于 Solaris 和 Linux 之间的运行时应用程序编程接口（application programming interfaces，API）的区别。如果您想了解这些区别的更多信息，请参阅运行时接口部分（第 7 页）。对应用程序作出所需的调整。
测试 — 当应用程序被完全地重新构建后，进行彻底的验证测试。
第 4 步：在目标 Linux 平台上构建和测试您的应用程序。
安装 Linux 环境 — 在目标硬件上安装 Linux 和 GNU 工具。
复制并重新构建应用程序 — 把您的源代码树和 makefile 复制到新的 Linux 机器上并重新构建应用程序。如果您没完成第 3 步，那么您可能需要修改应用程序，以适应 Solaris 和 Linux 之间运行时 API 的区别。最后，如果您的应用程序包含任何特定于 UltraSPARC 的代码，那么，请作出所需的修改，以解决那部分代码的问题。
修改安装例程，以适应目标 Linux 平台。各种 Linux 平台（分发版）的配置和启动文件的位置稍有不同。
测试 — 在结束移植前，对移植的应用程序运行彻底的验证测试套件。另外，在目标 Linux 平台上测试配置和安装。
警告！许可证和版权条款 — 当您移植到 Linux 并把您的应用程序和开放源代码的库链接时，请注意和这些库有关的许可证和版权。至少来说，您新移植的 C/C++ 应用程序将被链接到 GNU C/C++ 运行时库。这些库受 GNU Lesser General Public License 的保护。如果您移植的软件是专利性质的并且您想在用 GNU 工具构建该软件后出售它，那么谨慎的作法是完全理解 GNU General Public License 和 GNU Lesser General Public License（www.gnu.org/licenses/licenses.html）中列出的条款和条件。如果您的软件和受 GNU 许可证保护的库链接，那么 GNU 许可证中的某些条款和条件将对您的软件也适用。
java 应用程序的移植指南
第 1 步 — 下载所需的开发工具。
第 2 步 — 在目标 Linux 平台上使用应用程序。
第 1 步：下载
把用 Java 写的应用程序的开发从 Solaris 移到 Linux 是很简单的。您移植任务所需的工具有：
Java 2 Developer Kit 的 Linux 版包括重建的 Java 虚拟机（Java Virtual Machine，JVM），该 JVM 有改进的即时（just-in-time）编译功能 ibm.com/developerworks/java/jdk/linux130/
GCC 工具套件包含一个 Java 编译器（GCJ）gnu.org/software/gcc/java/
第 2 步：在目标 Linux 平台上使用应用程序
无论 JVM 运行在什么操作系统上，JVM 接受同样的字节码，所以您可以选择在某个操作系统中编译 Java 源文件，然后在另一操作系统中运行生成的类文件。例如，如果 Linux 是您的主要开发平台，那么您在 Linux 上创建的 Java 类文件能同样好地运行在 Solaris 或其它有兼容 JVM 的平台上。
运行时接口
尽管 Linux 和 Solaris 的绝大部分运行时接口是相同的，但有些地方还是有区别的。在您的应用程序中，每处用到 Linux 上没有或不完全相同的 Solaris 接口的地方都需要被修改，否则您的应用程序无法被正确地构建。以下列出的是有区别的地方。
系统调用、C 库和 C++ 库
API 差别 — Solaris 内核提供逻辑卷支持、文件的访问控制表（Access control list，ACL）的管理和系统审计日志功能。Linux API 中的这些功能（如果有的话）与 Solaris 上的并不相同。还有，在缺省情况下，Linux 不支持 STREAMS。在网络中用到 STREAMS 的应用程序需要改用 POSIX 套接字。另外，不少 Linux 上也有的 Solaris API 使用不同的返回和参数类型，或在不同的头文件中声明。但是，这些差别往往不大，通常不需要在应用程序中修改代码。
C++ 库 — Solaris Forte 6 C++ Compiler 包含三个类库：复数（-compat=4）、经典 iostream 和 Standard C++ Library（它包含标准的复数和 iostream）。GCC 只包含 Standard C++ Library。如果所移植的应用程序使用 -compat=4 复数库或经典 iostream 库，那么应用程序需改用包含在 Standard C++ Library 中的那些库的标准版本。作这种修改的额外好处是提高了应用程序的可移植性。
桌面：CDE 对 GNOME/KDE
图形用户界面（graphical user interface，GUI）— Solaris 的缺省桌面 Common Desktop Environment（CDE）并不包含在常见的 Linux 分发版中。对于要求 CDE 的应用程序或偏爱这种特别的 GUI 环境的用户，CDE 的 Linux 版本可从 Xi Graphics（www.xig.com）以他们的 DeXtop 产品的形式获得。在 Linux 上运行 DeXtop 使 Solaris 用户置身于熟悉的 GUI 环境从而使他们很容易地适应转移到 Linux 所带来的变化。
DeXtop 要求使用也是由 Xi Graphics 提供的 Accelerated-X Linux X-Server。尽管 XFree86 Linux X-Server 可以和 DeXtop 一起运行，但是 Xi Graphics 并不正式支持在 XFree86 上运行 DeXtop。
线程和进程管理
线程／轻量级进程（Light Weight Process，LWP）支持 — Solaris 支持 POSIX 线程和特定于 Solaris 的线程模型。如果所移植的应用程序使用特定于 Solaris 的线程 API，那么，最好修改应用程序，使其改用 POSIX 线程。POSIX 线程的可移植性更好而且 Linux 也支持它。
进程管理：/proc 文件系统 — /proc 伪文件系统提供了访问内核数据结构的方便的方法。在 Solaris 上，/proc 包括关于活动的进程和线程的信息，/proc 还提供控制这些进程和线程的接口。Solaris 上的 /proc 控制接口通常被调试器用来跟踪程序的执行。在 Linux 上，/proc 并不提供进程控制接口。在 Linux 上调试时，为了控制进程，请用 ptrace() API 而不是 /proc。
运行时要考虑的因素
系统管理：一般地说，管理 Linux 和管理任何其它 UNIX 操作系统非常相似。但在某些命令和任务的细节上是有差别的。IBM 和 UNIXGuide（unixguide.net/unixguide.cgi）已出版了比较图表，该图表不仅总结了 Solaris 和 Linux 之间的一些差别，还总结了 AIX 和其它版本的 UNIX 之间的差别。有经验的 Solaris 系统管理员不会遇到多大困难就能得心应手地用 Linux。
其它第三方工具、实用程序和库：许多 Solaris 上常见的流行的第三方工具、实用程序和库在 Linux 上也有，例如：
Rational Rose 和其它 Rational 产品在 Solaris 和 Linux 上都能用。
Rogue Wave SourcePro C++ 库在 Forte/Solaris 上能用，在 GCC/Solaris 和 GCC/Linux 上也能用。
Trolltech Qt C++ GUI 框架在 Solaris 和 Linux 上都能用。
由于 Linux 越来越受到欢迎，支持 Linux 的第三方供应商的数量在不断增加。
尾数格式 — Sun SPARC 和 UltraSPARC 处理器用大尾数法格式存储整数。如果您想把应用程序移植到使用小尾数法的 Linux 版本，例如 Linux/Intel，那么您必须解决应用程序中所有的尾数格式的相关性，以使应用程序能正确运行。另一种方法是把应用程序移植到 Linux/PowerPC、zSeries 上的 Linux 或 Linux/UltraSPARC（它们都是大尾数法平台）而不是 Linux/Intel。
从 Linux 移植到 zSeries 上的 Linux
现在移植到一个平台上（比如说 Intel）的 Linux 已完成，那么移植到其它硬件平台上的 Linux 怎样呢？简短的回答是：这很容易。
由于以下两个原因，我们选择以 zSeries 为例。
zSeries 是容易地从一种 Linux 移植到另一种 Linux 的好例子，因为 zSeries 体系结构和 Intel 体系结构完全不同。许多 ISV 先把他们的 UNIX 应用程序移植到 Intel 上的 Linux，这当然是自然的选择。接着再把应用程序移植到 zSeries 上的 Linux 就不需要太多的努力。
由于 zSeries 在虚拟化领域的独特功能及其硬件可靠性和可用性，所以，对您来说，zSeries 可能是有吸引力的平台。
为什么要移植到 zSeries 上的 Linux？
zSeries 上的 Linux 是纯粹的 Linux：它不是现有的 zSeries 操作系统上特别的 Linux，也不是为 zSeries 体系结构而修改的 Linux 的特别版本。zSeries 上的 Linux 的特征与其它平台上的 Linux 的特征相同，例如它是纯粹的 ASCII 环境。对于所有的体系结构，绝大部分的 Linux 结构是相同的。和 zSeries 相关的修改使 Linux 能和 zSeries 内存、zSeries 磁盘及通信硬件进行通信。Linux 和应用程序的接口及 Linux 和用户的界面并不受到影响。
应用程序的优点 — 您在 zSeries 上的 Linux 中的 Linux/UNIX 应用程序使您能访问存储在 zSeries 环境中的企业数据（后端集成）。这样提高了响应速度，减少了不必要的数据复制。zSeries 出众的容量、可伸缩性、可靠性、可用性和安全性使之成为企业服务器应用程序的完美部署平台。另外，在商务环境中，zSeries 上的 Linux 减少了服务器的数量，从而简化操作并降低成本。
zSeries 上的 Linux 移植提示和技巧
这些提示和技巧是由一个 IBM 技术小组总结的，该小组负责把应用程序移植到 zSeries 上的 Linux。该文档的全文可从 ibm.com/servers/esdd/articles/linux_s390/index.html 获得。
小尾数法到大尾数法
S/390 是大尾数法系统。如果代码要处理由小尾数法系统上产生的面向字节的数据，那么这些代码可能需要某种字节对换。这些数据可能需要被重新生成，如果这不可能（例如，共享的文件），那么，应用程序需被修改，以适合处理小尾数法数据。如果原来的平台是大尾数法平台（例如 UltraSPARC、IBM ~ pSeries™……），那么就不存在这个问题。
汇编代码
汇编代码需用 S/390 汇编器重写。所有的操作码需改成 S/390 操作码。如果应用程序代码使用汇编头文件，那么就需要该头文件的 S/390 版本。S/390 汇编代码的 Linux 版本使用 S/390 操作码但遵守 GNU 汇编器的语法约定。您可以从 www.gnu.org/manual/gas-2.9.1/as.html 下载 GNU 汇编器手册。
绝对地址和高阶位
出于各种目的，一些应用程序使用硬编码地址。一个可能的目的是在内存中定义固定的页，用于分配或用 mmap() 来内存映射。mmap() 调用的一种形式允许页固定。在这种模式中，mmap() 试图使用在所请求的地址的存储器来内存映射。在 Intel 平台上，这个地址可能被指定在 zSeries 上的 Linux 无法使用的地方。
每个平台很可能选择不同的程序堆栈位置、系统库、堆等等，所以在移植到其它系统的时候，硬编码地址往往是糟糕的选择。zSeries 寻址方式还忽略高阶位，所以硬编码地址 0x80000000（高阶位是 1）将被转换成 0x00000000，而这是 zSeries 上的保留地址。在生成地址时，对地址的算术运算也能使高阶位变为 1。
如果应用程序因使用绝对地址而产生段违例或其它错误，那么必须修改它。/proc//map 显示一个活动的进程是怎样使用它的寻址空间内的存储范围的。如果代码必须使用绝对地址，那么这个 map 可被用来查找还未被保留的地址范围。
某些地址字段的高阶位可能要用“AND”来变为 0（31 位模式位）。如果该地址被用于算术运算，那么您必须这样做。
应用程序开发工具
部署应用程序要求在目标服务器上有一套健壮的工具。在 ibm.com/servers/eserver/zseries/os/linux/ldt/ 的 Web 站点描述了将部署到 zSeries 上的 Linux 的 C/C++ 应用程序的开发或移植的几个阶段并给出在每个阶段中有用的工具列表。
杂项
ptrace 和返回结构 — ptrace 和返回结构的使用与体系结构相关。
Configuration/build/Makefile 脚本或文件 — 很可能需要增加对 S/390 平台的支持。
proc 文件系统 — 有些区别，例如：
/proc/cpuinfo 格式不同
/proc/interrupts 未被实现
/proc/stat 不包含 INTR 信息
char 是无符号的 — 在 zSeries 上，字符类型 char 被缺省地解释为无符号的 char，而在其它平台上，char 被解释为有符号的 char。
Va_args — 在 Linux 的 zSeries 版本中，va_list 的定义与其它平台的不同。如果您的应用程序简单地使用一个 C 赋值语句来复制 va_list，那么在 Linux 的 zSeries 版本中，您必须换用 _va_ 宏来复制。
㈥ linux共享内存和mmap的区别
共享内存的创建
根据理论：
1. 共享内存允许两个或多个进程共享一给定的存储区，因为数据不需要来回复制，所以是最快的一种进程间通信机制。共享内存可以通过mmap()映射普通文件（特殊情况下还可以采用匿名映射）机制实现，也可以通过系统V共享内存机制实现。应用接口和原理很简单，内部机制复杂。为了实现更安全通信，往往还与信号灯等同步机制共同使用。
mmap的机制如：就是在磁盘上建立一个文件，每个进程存储器里面，单独开辟一个空间来进行映射。如果多进程的话，那么不会对实际的物理存储器（主存）消耗太大。
shm的机制：每个进程的共享内存都直接映射到实际物理存储器里面。
结论：
1、mmap保存到实际硬盘，实际存储并没有反映到主存上。优点：储存量可以很大（多于主存）（这里一个问题，需要高手解答,会不会太多拷贝到主存里面？？？）；缺点：进程间读取和写入速度要比主存的要慢。
2、shm保存到物理存储器（主存），实际的储存量直接反映到主存上。优点，进程间访问速度（读写）比磁盘要快；缺点，储存量不能非常大（多于主存）
使用上看：如果分配的存储量不大，那么使用shm；如果存储量大，那么使用shm。
参看网络：http://ke..com/view/1499209.htm
mmap就是一个文件操作
看这些网络的描述：
mmap()系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以向访问普通内存一样对文件进行访问，不必再调用read()，write（）等操作。 成功执行时，mmap()返回被映射区的指针，munmap()返回0。失败时，mmap()返回MAP_FAILED[其值为(void *)-1]，munmap返回-1。errno被设为以下的某个值 EACCES：访问出错EAGAIN：文件已被锁定，或者太多的内存已被锁定EBADF：fd不是有效的文件描述词EINVAL：一个或者多个参数无效 ENFILE：已达到系统对打开文件的限制ENODEV：指定文件所在的文件系统不支持内存映射ENOMEM：内存不足，或者进程已超出最大内存映射数量 EPERM：权能不足，操作不允许ETXTBSY：已写的方式打开文件，同时指定MAP_DENYWRITE标志SIGSEGV：试着向只读区写入 SIGBUS：试着访问不属于进程的内存区参数fd为即将映射到进程空间的文件描述字，
一般由open()返回，同时，fd可以指定为-1，此时须指定 flags参数中的MAP_ANON，表明进行的是匿名映射（不涉及具体的文件名，避免了文件的创建及打开，很显然只能用于具有亲缘关系的进程间通信）
相关文章参考：
mmap函数是unix/linux下的系统调用，来看《Unix Netword programming》卷二12.2节有详细介绍。
mmap系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式，进程可以像读写内存一样对普通文件的操作。而Posix或系统V的共享内存IPC则纯粹用于共享目的，当然mmap()实现共享内存也是其主要应用之一。
mmap系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问，不必再 调用read()，write（）等操作。mmap并不分配空间, 只是将文件映射到调用进程的地址空间里, 然后你就可以用memcpy等操作写文件, 而不用write()了.写完后用msync()同步一下, 你所写的内容就保存到文件里了. 不过这种方式没办法增加文件的长度, 因为要映射的长度在调用mmap()的时候就决定了.
简单说就是把一个文件的内容在内存里面做一个映像，内存比磁盘快些。
基本上它是把一个档案对应到你的virtual memory 中的一段，并传回一个指针。
重写总结：
1、mmap实际就是操作“文件”。
2、映射文件，除了主存的考虑外。shm的内存共享，效率应该比mmap效率要高（mmap通过io和文件操作，或“需要写完后用msync()同步一下”）；当然mmap映射操作文件，比直接操作文件要快些;由于多了一步msync应该可以说比shm要慢了吧？？？
3、另一方面，mmap的优点是，操作比shm简单（没有调用比shm函数复杂），我想这也是许多人喜欢用的原因，包括nginx。
缺点，还得通过实际程序测试，确定！！！
修正理解（这也真是的，这个网站没办法附加；只能重写了）：
今天又细心研究了一下，发现网络这么一段说明：
2、系统调用mmap()用于共享内存的两种方式：
（1）使用普通文件提供的内存映射：适用于任何进程之间；此时，需要打开或创建一个文件，然后再调用mmap()；典型调用代码如下：
fd=open(name, flag, mode);
if(fd<0)
...
ptr=mmap(NULL, len , PROT_READ|PROT_WRITE, MAP_SHARED , fd , 0); 通过mmap()实现共享内存的通信方式有许多特点和要注意的地方，我们将在范例中进行具体说明。
（2）使用特殊文件提供匿名内存映射：适用于具有亲缘关系的进程之间；由于父子进程特殊的亲缘关系，在父进程中先调用mmap()，然后调用fork()。那么在调用fork()之后，子进程继承父进程匿名映射后的地址空间，同样也继承mmap()返回的地址，这样，父子进程就可以通过映射区域进行通信了。注意，这里不是一般的继承关系。一般来说，子进程单独维护从父进程继承下来的一些变量。而mmap()返回的地址，却由父子进程共同维护。
看了一下windows“内存映射文件”：http://ke..com/view/394293.htm
内存映射文件与虚拟内存有些类似，通过内存映射文件可以保留一个地址空间的区域，同时将物理存储器提交给此区域，只是内存文件映射的物理存储器来自一个已经存在于磁盘上的文件，而非系统的页文件，而且在对该文件进行操作之前必须首先对文件进行映射，就如同将整个文件从磁盘加载到内存。由此可以看出，使用内存映射文件处理存储于磁盘上的文件时，将不必再对文件执行I/O操作，这意味着在对文件进行处理时将不必再为文件申请并分配缓存，所有的文件缓存操作均由系统直接管理，由于取消了将文件数据加载到内存、数据从内存到文件的回写以及释放内存块等步骤，使得内存映射文件在处理大数据量的文件时能起到相当重要的作用。另外，实际工程中的系统往往需要在多个进程之间共享数据，如果数据量小，处理方法是灵活多变的，如果共享数据容量巨大，那么就需要借助于内存映射文件来进行。实际上，内存映射文件正是解决本地多个进程间数据共享的最有效方法。
这里再总结一次：
1、mmap有两种方式，一种是映射内存，它把普通文件映射为实际物理内存页，访问它就和访问物理内存一样（这也就和shm的功能一样了）（同时不用刷新到文件）
2、mmap可以映射文件，不确定会不会像windows“内存映射文件”一样的功能，如果是，那么他就能映射好几G甚至好几百G的内存数据，对大数据处理将提供强大功能了？？？
3、shm只做内存映射，和mmap第一个功能一样！只不过不是普通文件而已，但都是物理内存。