Intel Windows7 USB3.0 Creator|为Win7安装镜像加入USB3.0支持工具

由于Intel skylake或braswell芯片组的系统没有USB2.0。 所有端口都是usb3.0和Windows7安装USB介质不包含所需的驱动程序的都会影响到安装Windows7,导致不能读取U盘或是键盘鼠标不能使用的情况,我们可以使用Intel Windows7 USB3.0 Creator 为Win7安装盘加入USB3.0驱动支持,这样也就解决了安装系统时出现不能识别USB3.0或是设备不能使用的情况了。

使用方法:

一、使用Windows 7 USB DVD Download Tool或者软碟通(UltraISO)制作Win7原版安装盘。(不要使用ghost镜像制作,否则后续会有报错)
二、:解压缩之前下载的软件,在解压缩路径下右键以管理员方式运行Installer_Creator.exe;

http://webdoc.lenovo.com.cn/lenovowsi/new_cskb/uploadfile/20151120162739459.jpg

三:在弹出界面中点击右侧的选择按钮,选中U盘所在分区;

http://webdoc.lenovo.com.cn/lenovowsi/new_cskb/uploadfile/20151120163039496.jpg

四:点击Create Image开始往U盘中添加程序,过程会比较长,Intel官方数据是15分钟,实测超过20分钟;

http://webdoc.lenovo.com.cn/lenovowsi/new_cskb/uploadfile/20151120163714151.jpg

http://webdoc.lenovo.com.cn/lenovowsi/new_cskb/uploadfile/20151120163727949.jpg

六:在出现Upadte finished!后创建结束,现在就可以使用这个U盘在USB 3.0接口上安装系统了。

http://webdoc.lenovo.com.cn/lenovowsi/new_cskb/uploadfile/20151120163823796.jpg

解决Skylake平台intel 六代以上cpu无法安装原版WIN7系统方法

https://blog.csdn.net/u012987386/article/details/85255911

英特尔推出了全新的Skylake平台,CPU的效能进一步提升,随后各大PC厂商都给旗下的笔记本电脑升级到了最新的Skylake平台。随后很多购买最新款笔记本电脑的用户,由于不太适应最新的Windows 10操作系统,重新安装Windows7的时候却发现在intel 六代cpu和intel 七代CPU平台上无法识别USB接口了,鼠标、U盘、键盘统统无法用了,这是什么问题呢?

原来问题的原因是英特尔Skylake这代芯片组(100,200系列)把EHCI主控替换成了XHCI主控,Windows10和Windows8是原生带有XHCI主控驱动的,而稍微老点的Windows 7系统原生是没有XHCI主控的驱动的,所以就出现了以上的情况,我们今天就来解决掉这个无语的问题。

Intel Skylake是英特尔第六代微处理器架构,采用14纳米制程,是Intel Haswell微架构及其制程改进版Intel Broadwell微架构的继任者。Intel Skylake已经在2015年8月5日20:00发布,也就是北京时间九点整。

接口变更为LGA1151,必须搭配Intel的100系列芯片组才能使用。

解决Win7在intel 六代cpu和intel 七代CPU平台上无法识别USB接口之前,我们先来简单了解下XHCI的相关知识和造成问题的原因。

6代以后的intel CPU支持的是USB3.0以上,而win7是09年的产物,自己系统只能带USB2.0驱动,结果就是安装以后鼠标、键盘不管用,没法下一步,或者用PS2接口鼠标键盘(未验证),或者在win7系统内加好USB3.0驱动,再进行安装。下面只说第二种方式。

XHCI(eXtensible Host Controller Interface)可扩展的主机控制器接口,是Intel开发的USB主机控制器,本代100系列芯片的USB协议采用的就是XHCI主控,是面向USB 3.0标准的,同时也兼容2.0以下的设备。上代Broadwell之前采用的都是EHCI主控,主要是面向2.0标准的。而原生win7系统只有EHCI驱动而没有XHCI驱动

那既然知道失效是由于缺少驱动,那装上不就好了?然而这个方法并没有什么用,因为安装XHCI驱动需要鼠标和键盘来操作,然后Win7下是无法识别USB接口的,不过通过PS/2连接的鼠标键盘是能正常工作的,可惜绝大多数笔记本都不可能带有PS/2接口,这个问题可以说是相当的烦人,不过好在厂商也意识到这个问题了,推出了Win7 USB补丁。下面小编就给详细介绍如何制作集成USB3.0驱动的新ISO镜像。

问题解决方法:

需要用到的软件/硬件工具:

1、一台可以正常工作的电脑

2、Win7 USB Patcher,可点击下载,来自华擎官网。(技嘉、华硕、微星也有自己的工具,操作方式都大同小异,下面的操作都以华擎的工具为例做演示)

3、Win7的原版的ISO镜像

具体操作流程:

把上述工具准备好,用能正常工作的电脑来完成以下操作。

首先把准备好的ISO镜像用WinRAR/好压/360压缩/7z等解压工具把里面的文件解压到硬盘上任意文件夹上。

把下载好的华擎破解软件解压出来,然后运行这个Win7USBPatcher。

第一步:到这里就视情况选择,如果是准备了U盘的话就选择第一个,如果是准备了其他储存介质的就选其他。我们这里就直接选择本地硬盘分区,那我们这里选第二个,Create a XXXX installation iso file for a cd 。然后点右下角的“Next”。

第二步:然后选择“Browse”,下面的路径就选刚才解压出来原版ISO文件的文件夹。再点击“Next”

第三步:选择要保存制作usb3.0驱动的新iso路径,然后再点击“Next”

第四步:制作Win7 iso新镜像文件,直接点击“Start”就可以开始了。然后你只要等待5~20分钟即可完成。

制作成功之后,你的U盘中的win7安装包中就已经注入了XHCI的驱动了,然后就可以用新iso镜像文件按照正常的顺序的安装Windows7操作系统了。此方法目前只对WIN7 64位有效。

U盘安装win7(usb3.0驱动问题)– 华硕工具

用Windows USB Installation Tool制作U盘windows7安装盘

用Windows USB Installation Tool制作U盘windows7安装盘

最近准备给新买的电脑用U盘安装WIN7系统时,出现如下提示:缺少所需的CD/DVD驱动器设备驱动程序….,点浏览查看不到任何U盘信息。以前出现这个提示,占浏览找到驱动程序,就可以正常安装了。111

但我的主板是Z170A平台,在Z170平台安装Win7系统出现上述原因主要是Skylake项比早期的规划方案,增加了对USB 3.1接口的支持,因此将不再支持原有的EHCI主控,变更为最新的XHCI主控。这一变动导致用户在安装Win7的界面中会出现USB接口全部失灵的状况,不仅无法使用USB键鼠对安装界面进行操作,同时系统也无法读取U盘中的安装文件。以下教程就是为了解决这个问题

第一步:首先,准备好工具(下面有下载地址)

1.制作工具,我这里选择华硕的WIN7 USB补丁软件!

官方下载:
WIN7 USB补丁工具

本地下载:
USB补丁软件(Windows USB Installation ToolV1_00_08

虚拟光驱工具:ultraiso_v9.5.3.2901  下载并安装好,当然如果你的电脑里安装有其他虚拟光驱软件,这个工具就不用下载了。

2.Windows 7 With Sp1 64位简体中文旗舰版,其他版本,自行搜索。

windows7 msdn简体中文版BT下载cn_windows_7_professional_with_sp1_x64_dvd_u_677031.iso

第二步:制作过程

1.在你下载的WIN7镜像上单击右键,用ultraiso加载虚拟光驱。

12

插入你需要制作安装盘的U盘(至少8G),淘宝上面十几块钱的那种就不要做了。容易出错。

2.打开制作工具

3

下一步
4

选择刚才加载的虚拟光驱

5

选择你的U盘

6

最近一次确认你的U盘是不是有重要数据,没有就确定。

7

制作过程得二十几多分钟。耐心等待就行了。

9

安装完成后,再用U盘引导,就能正常安装了。

8

svn报错:“Previous operation has not finished; run ‘cleanup’ if it was interrupted“ 的解决方法

今天改完代码提交时,提交接近完成但窗口还未关闭电脑蓝屏了。夏天来了,电脑比人还怕热啊~~~   心里咯噔一下,估计svn又会出一些莫名其妙的问题了。

果然,待电脑重启后开eclipse,文件还是新增状态,提交报错,提示需要执行clean up 。

但svn执行clean up命令时报错“Previous operation has not finished; run ‘cleanup’ if it was interrupted”。 无论你到那个父层次的目录执行“clean up “,都是报一样的错。后将代码删除,想重新check out 都不行。

此时测试还在催着交代码,真是屋漏偏逢连夜雨,越急越容易出错。

后上网搜索,本地.svn\wc.db数据库文件里面存储了svn的operation,表名是work_queue。

.db数据库文件可以用sqlite3打开。到网上下载sqlite3.exe,解压到D:\Offsite\.svn文件夹下,解压后的sqlite3.exe才475KB大小。

1. 运行cmd,进入到D:\Offsite\.svn文件夹下,执行sqlite3 wc.db,打开数据库

 

2. 执行.table 可以查看表名

 

3. 执行delete from work_queue; 命令。

 

4. 重试 clean up 操作,问题解决。

修改Exchange最大并发连接数

Exchange并发连接数默认都很小,入站并发数 和 出站并发数 默认都为20;对于一般企业而言,20个并发连接数足够用了,但是对于邮件较多的企业,可能同时接收/发送的邮件数量远远超过20,如果超过,Exchange就会返回错误信息,说是最大并发连接数已超过限制,如下:

421 4.3.2 The maximum number of concurrent connections has exceeded a limit, closing transmission channel

解决办法(以Exchange 2010为例):
通过Exchange的Shell命令和EMC管理控制台修改最大并发连接数。

修改入站最大并发连接数:

1、在服务器上运行Exchange Shell命令管理界面EMS
查看当前所有接收连接器的最大并发连接数:

[PS] C:\Windows\system32>get-receiveconnector * | ft Name,MaxInboundconnectionPersource

Name                                                        MaxInboundConnectionPerSource
----                                                        -----------------------------
Default EXCHANGE2010                                        20
Client EXCHANGE2010                                         20

2、修改默认接收连接器“Default EXCHANGE2010”的最大并发连接数为500:

[PS] C:\Windows\system32>Set-receiveconnector -identity "Default EXCHANGE2010" -MaxInboundconnectionPersource 500

3、再次查看默认接收连接器“Default EXCHANGE2010”的最大并发连接数

[PS] C:\Windows\system32>get-receiveconnector * | ft Name,MaxInboundconnectionPersource

Name                                                        MaxInboundConnectionPerSource
----                                                        -----------------------------
Default EXCHANGE2010                                        500
Client EXCHANGE2010                                         20

4
修改出站最大并发连接数:

1、打开Exchange管理控制台EMC,依次打开“服务器配置”–“集线器传输”,在右侧服务器上单击右键,点击“属性”
2
2、在“限制”–“连接限制”选项下,修改默认 最大并发出站连接数 即可
3

WINDOWS操作系统中可以允许最大的线程数

WINDOWS操作系统中可以允许最大的线程数

默认情况下,一个线程的栈要预留1M的内存空间
而一个进程中可用的内存空间只有2G,所以理论上一个进程中最多可以开2048个线程
但是内存当然不可能完全拿来作线程的栈,所以实际数目要比这个值要小。
你也可以通过连接时修改默认栈大小,将其改的比较小,这样就可以多开一些线程。
如将默认栈的大小改成512K,这样理论上最多就可以开4096个线程。

即使物理内存再大,一个进程中可以起的线程总要受到2GB这个内存空间的限制。
比方说你的机器装了64GB物理内存,但每个进程的内存空间还是4GB,其中用户态可用的还是2GB。

如果是同一台机器内的话,能起多少线程也是受内存限制的。每个线程对象都要站用非页面内存,而非页面内存也是有限的,当非页面内存被耗尽时,也就无法创建线程了。

如果物理内存非常大,同一台机器内可以跑的线程数目的限制值会越来越大。

在Windows下写个程序,一个进程Fork出2000个左右线程就会异常退出了,为什么?

这个问题的产生是因为windows32位系统,一个进程所能使用的最大虚拟内存为2G,而一个线程的默认线程栈StackSize为1024K(1M),这样当线程数量逼近2000时,2000*1024K=2G(大约),内存资源就相当于耗尽。

 

MSDN原文:

“The number of threads a process can create is limited by the available virtual memory. By default, every thread has one megabyte of stack space. Therefore, you can create at most 2,028 threads. If you reduce the default stack size, you can create more threads. However, your application will have better performance if you create one thread per processor and build queues of requests for which the application maintains the context information. A thread would process all requests in a queue before processing requests in the next queue.”

 

如何突破2000个限制?

可以通过修改CreateThread参数来缩小线程栈StackSize,例如

#define   MAX_THREADS   50000

DWORD   WINAPI   ThreadProc(   LPVOID   lpParam   ){
while(1){
Sleep(100000);
}
return   0;
}

int   main()   {
DWORD   dwThreadId[MAX_THREADS];
HANDLE   hThread[MAX_THREADS];

for(int   i   =   0;   i   <   MAX_THREADS;   ++i)
{
hThread[i]  = CreateThread(0,  64, ThreadProc, 0, STACK_SIZE_PARAM_IS_A_RESERVATION,   &dwThreadId[i]);

if(0   ==   hThread[i])
{
DWORD   e   =   GetLastError();
printf("%d\r\n",e);
break;
}
}
ThreadProc(0);
}

 

服务器端程序设计

如果你的服务器端程序设计成:来一个client连接请求则创建一个线程,那么就会存在2000个限制(在硬件内存和CPU个数一定的情况下)。建议如下:

The “one thread per client” model is well-known not to scale beyond a dozen clients or so. If you’re going to be handling more than that many clients simultaneously, you should move to a model where instead of dedicating a thread to a client, you instead allocate an object. (Someday I’ll muse on the duality between threads and objects.) Windows provides I/O completion ports and a thread pool to help you convert from a thread-based model to a work-item-based model.

1. Serve many clients with each thread, and use nonblocking I/O and level-triggeredreadiness notification
2. Serve many clients with each thread, and use nonblocking I/O and readiness changenotification
3. Serve many clients with each server thread, and use asynchronous I/O

 

Pushing the Limits of Windows: Processes and Threads


This is the fourth post in my Pushing the Limits of Windows series that explores the boundaries of fundamental resources in Windows. This time, I’m going to discuss the limits on the maximum number of threads and processes supported on Windows. I’ll briefly describe the difference between a thread and a process, survey thread limits and then investigate process limits. I cover thread limits first since every active process has at least one thread (a process that’s terminated, but is kept referenced by a handle owned by another process won’t have any), so the limit on processes is directly affected by the caps that limit threads.

Unlike some UNIX variants, most resources in Windows have no fixed upper bound compiled into the operating system, but rather derive their limits based on basic operating system resources that I’ve already covered. Process and threads, for example, require physical memory, virtual memory, and pool memory, so the number of processes or threads that can be created on a given Windows system is ultimately determined by one of these resources, depending on the way that the processes or threads are created and which constraint is hit first. I therefore recommend that you read the preceding posts if you haven’t, because I’ll be referring to reserved memory, committed memory, the system commit limit and other concepts I’ve covered. Here’s the index of the entire Pushing the Limits series. While they can stand on their own, they assume that you read them in order.

Pushing the Limits of Windows: Physical Memory

Pushing the Limits of Windows: Virtual Memory

Pushing the Limits of Windows: Paged and Nonpaged Pool

Pushing the Limits of Windows: Processes and Threads

Pushing the Limits of Windows: Handles

Pushing the Limits of Windows: USER and GDI Objects – Part 1

Pushing the Limits of Windows: USER and GDI Objects – Part 2

Processes and Threads

A Windows process is essentially container that hosts the execution of an executable image file. It is represented with a kernel process object and Windows uses the process object and its associated data structures to store and track information about the image’s execution. For example, a process has a virtual address space that holds the process’s private and shared data and into which the executable image and its associated DLLs are mapped. Windows records the process’s use of resources for accounting and query by diagnostic tools and it registers the process’s references to operating system objects in the process’s handle table. Processes operate with a security context, called a token, that identifies the user account, account groups, and privileges assigned to the process.

Finally, a process includes one or more threads that actually execute the code in the process (technically, processes don’t run, threads do) and that are represented with kernel thread objects. There are several reasons applications create threads in addition to their default initial thread: processes with a user interface typically create threads to execute work so that the main thread remains responsive to user input and windowing commands; applications that want to take advantage of multiple processors for scalability or that want to continue executing while threads are tied up waiting for synchronous I/O operations to complete also benefit from multiple threads.

Thread Limits

Besides basic information about a thread, including its CPU register state, scheduling priority, and resource usage accounting, every thread has a portion of the process address space assigned to it, called a stack, which the thread can use as scratch storage as it executes program code to pass function parameters, maintain local variables, and save function return addresses. So that the system’s virtual memory isn’t unnecessarily wasted, only part of the stack is initially allocated, or committed and the rest is simply reserved. Because stacks grow downward in memory, the system places guard pages beyond the committed part of the stack that trigger an automatic commitment of additional memory (called a stack expansion) when accessed. This figure shows how a stack’s committed region grows down and the guard page moves when the stack expands, with a 32-bit address space as an example (not drawn to scale):

image

The Portable Executable (PE) structures of the executable image specify the amount of address space reserved and initially committed for a thread’s stack. The linker defaults to a reserve of 1MB and commit of one page (4K), but developers can override these values either by changing the PE values when they link their program or for an individual thread in a call to CreateThread. You can use a tool like Dumpbinthat comes with Visual Studio to look at the settings for an executable. Here’s the Dumpbin output with the /headers option for the executable generated by a new Visual Studio project:

image

Converting the numbers from hexadecimal, you can see the stack reserve size is 1MB and the initial commit is 4K and using the new Sysinternals VMMap tool to attach to this process and view its address space, you can clearly see a thread stack’s initial committed page, a guard page, and the rest of the reserved stack memory:

image

Because each thread consumes part of a process’s address space, processes have a basic limit on the number of threads they can create that’s imposed by the size of their address space divided by the thread stack size.

32-bit Thread Limits

Even if the thread had no code or data and the entire address space could be used for stacks, a 32-bit process with the default 2GB address space could create at most 2,048 threads. Here’s the output of the Testlimit tool running on 32-bit Windows with the –t switch (create threads) confirming that limit:

image

Again, since part of the address space was already used by the code and initial heap, not all of the 2GB was available for thread stacks, thus the total threads created could not quite reach the theoretical limit of 2,048.

I linked the Testlimit executable with the large address space-aware option, meaning that if it’s presented with more than 2GB of address space (for example on 32-bit systems booted with the /3GB or /USERVA Boot.ini option or its equivalent BCD option on Vista and laterincreaseuserva), it will use it. 32-bit processes are given 4GB of address space when they run on 64-bit Windows, so how many threads can the 32-bit Testlimit create when run on 64-bit Windows? Based on what we’ve covered so far, the answer should be roughly 4096 (4GB divided by 1MB), but the number is actually significantly smaller. Here’s 32-bit Testlimit running on 64-bit Windows XP:

image

The reason for the discrepancy comes from the fact that when you run a 32-bit application on 64-bit Windows, it is actually a 64-bit process that executes 64-bit code on behalf of the 32-bit threads, and therefore there is a 64-bit thread stack and a 32-bit thread stack area reserved for each thread. The 64-bit stack has a reserve of 256K (except that on systems prior to Vista, the initial thread’s 64-bit stack is 1MB). Because every 32-bit thread begins its life in 64-bit mode and the stack space it uses when starting exceeds a page, you’ll typically see at least 16KB of the 64-bit stack committed. Here’s an example of a 32-bit thread’s 64-bit and 32-bit stacks (the one labeled “Wow64” is the 32-bit stack):

image

32-bit Testlimit was able to create 3,204 threads on 64-bit Windows, which given that each thread uses 1MB+256K of address space for stack (again, except the first on versions of Windows prior to Vista, which uses 1MB+1MB), is exactly what you’d expect. I got different results when I ran 32-bit Testlimit on 64-bit Windows 7, however:

image

The difference between the Windows XP result and the Windows 7 result is caused by the more random nature of address space layout introduced in Windows Vista, Address Space Load Randomization (ASLR), that leads to some fragmentation. Randomization of DLL loading, thread stack and heap placement, helps defend against malware code injection. As you can see from this VMMap output, there’s 357MB of address space still available, but the largest free block is only 128K in size, which is smaller than the 1MB required for a 32-bit stack:

image

As I mentioned, a developer can override the default stack reserve. One reason to do so is to avoid wasting address space when a thread’s stack usage will always be significantly less than the default 1MB. Testlimit sets the default stack reservation in its PE image to 64K and when you include the –n switch along with the –t switch, Testlimit creates threads with 64K stacks.  Here’s the output on a 32-bit Windows XP system with 256MB RAM (I did this experiment on a small system to highlight this particular limit):

image

Note the different error, which implies that address space isn’t the issue here. In fact, 64K stacks should allow for around 32,000 threads (2GB/64K = 32,768). What’s the limit that’s being hit in this case? A look at the likely candidates, including commit and pool, don’t give any clues, as they’re all below their limits:

image

It’s only a look at additional memory information in the kernel debugger that reveals the threshold that’s being hit, resident available memory, which has been exhausted:

image

Resident available memory is the physical memory that can be assigned to data or code that must be kept in RAM. Nonpaged pool and nonpaged drivers count against it, for example, as does memory that’s locked in RAM for device I/O operations. Every thread has both a user-mode stack, which is what I’ve been talking about, but they also have a kernel-mode stack that’s used when they run in kernel mode, for example while executing system calls. When a thread is active its kernel stack is locked in memory so that the thread can execute code in the kernel that can’t page fault.

A basic kernel stack is 12K on 32-bit Windows and 24K on 64-bit Windows. 14,225 threads require about 170MB of resident available memory, which corresponds to exactly how much is free on this system when Testlimit isn’t running:

image

Once the resident available memory limit is hit, many basic operations begin failing. For example, here’s the error I got when I double-clicked on the desktop’s Internet Explorer shortcut:

image

As expected, when run on 64-bit Windows with 256MB of RAM, Testlimit is only able to create 6,600 threads – roughly half what it created on 32-bit Windows with 256MB RAM – before running out of resident available memory:

image

The reason I said “basic” kernel stack earlier is that a thread that executes graphics or windowing functions gets a “large” stack when it executes the first call that’s 20K on 32-bit Windows and 48K on 64-bit Windows. Testlimit’s threads don’t call any such APIs, so they have basic kernel stacks.

64-bit Thread Limits

Like 32-bit threads, 64-bit threads also have a default of 1MB reserved for stack, but 64-bit processes have a much larger user-mode address space (8TB), so address space shouldn’t be an issue when it comes to creating large numbers of threads. Resident available memory is obviously still a potential limiter, though. The 64-bit version of Testlimit (Testlimit64.exe) was able to create around 6,600 threads with and without the –n switch on the 256MB 64-bit Windows XP system, the same number that the 32-bit version created, because it also hit the resident available memory limit. However, on a system with 2GB of RAM, Testlimit64 was able to create only 55,000 threads, far below the number it should have been able to if resident available memory was the limiter (2GB/24K = 89,000):

image

In this case, it’s the initial thread stack commit that causes the system to run out of virtual memory and the “paging file is too small” error. Once the commit level reached the size of RAM, the rate of thread creation slowed to a crawl because the system started thrashing, paging out stacks of threads created earlier to make room for the stacks of new threads, and the paging file had to expand. The results are the same when the –n switch is specified, because the threads have the same initial stack commitment.

Process Limits

The number of processes that Windows supports obviously must be less than the number of threads, since each process has one thread and a process itself causes additional resource usage. 32-bit Testlimit running on a 2GB 64-bit Windows XP system created about 8,400 processes:

image

A look in the kernel debugger shows that it hit the resident available memory limit:

image

If the only cost of a process with respect to resident available memory was the kernel-mode thread stack, Testlimit would have been able to create far more than 8,400 threads on a 2GB system. The amount of resident available memory on this system when Testlimit isn’t running is 1.9GB:

image

Dividing the amount of resident memory Testlimit used (1.9GB) by the number of processes it created (8,400) yields 230K of resident memory per process. Since a 64-bit kernel stack is 24K, that leaves about 206K unaccounted for. Where’s the rest of the cost coming from? When a process is created, Windows reserves enough physical memory to accommodate the process’s minimum working set size. This acts as a guarantee to the process that no matter what, there will enough physical memory available to hold enough data to satisfy its minimum working set. The default working set size happens to be 200KB, a fact that’s evident when you add the Minimum Working Set column toProcess Explorer’s display:

image

The remaining roughly 6K is resident available memory charged for additional non-pageable memory allocated to represent a process. A process on 32-bit Windows will use slightly less resident memory because its kernel-mode thread stack is smaller.

As they can for user-mode thread stacks, processes can override their default working set size with the SetProcessWorkingSetSize function. Testlimit supports a –n switch, that when combined with –p, causes child processes of the main Testlimit process to set their working set to the minimum possible, which is 80K. Because the child processes must run to shrink their working sets, Testlimit sleeps after it can’t create any more processes and then tries again to give its children a chance to execute. Testlimit executed with the –n switch on a Windows 7 system with 4GB of RAM hit a limit other than resident available memory: the system commit limit:

image

Here you can see the kernel debugger reporting not only that the system commit limit had been hit, but that there have been thousands of memory allocation failures, both virtual and paged pool allocations, following the exhaustion of the commit limit (the system commit limit was actually hit several times as the paging file was filled and then grown to raise the limit):

image

The baseline commitment before Testlimit ran was about 1.5GB, so the threads had consumed about 8GB of committed memory. Each process therefore consumed roughly 8GB/6,600, or 1.2MB. The output of the kernel debugger’s !vm command, which shows the private memory allocated by each active process, confirms that calculation:

image

The initial thread stack commitment, described earlier, has a negligible impact with the rest coming from the memory required for the process address space data structures, page table entries, the handle table, process and thread objects, and private data the process creates when it initializes.

How Many Threads and Processes are Enough?

So the answer to the questions, “how many threads does Windows support?” and “how many processes can you run concurrently on Windows?” depends. In addition to the nuances of the way that the threads specify their stack sizes and processes specify their minimum working sets, the two major factors that determine the answer on any particular system include the amount of physical memory and the system commit limit. In any case, applications that create enough threads or processes to get anywhere near these limits should rethink their design, as there are almost always alternate ways to accomplish the same goals with a reasonable number. For instance, the general goal for a scalable application is to keep the number of threads running equal to the number of CPUs (with NUMA changing this to consider CPUs per node) and one way to achieve that is to switch from using synchronous I/O to using asynchronous I/O and rely on I/O completion ports to help match the number of running threads to the number of CPUs.

 

Win 7, Server 2008 R2最大线程数限制

 

 

 

最近在做压力测试时发现Win 7 和 Server 2008 R2 系统内线程数设为1500则无法创建线程池,深入分析发现32位和64位程序存在很大性能差异。

 

最大线程数:

32bit:1450

64bit:100000

测试代码如下:

[cpp] view plain copy

  1. #include “stdafx.h”  
  2. #include <stdio.h>  
  3. #include <windows.h>  
  4. DWORD CALLBACK ThreadProc(void*)  
  5. {
  6.     Sleep(INFINITE);
  7.     return 0;  
  8. }
  9. int __cdecl main(int argc, const char* argv[])  
  10. {
  11.     int i;  
  12.     for (i = 0; i < 100000; i++)   
  13.     {
  14.         DWORD id;  
  15.         HANDLE h = CreateThread(NULL,4096, ThreadProc, NULL, STACK_SIZE_PARAM_IS_A_RESERVATION, &id);  
  16.         if (!h)  
  17.             break;  
  18.         CloseHandle(h);
  19.         printf(“%d\n”, i);  
  20.     }
  21.     // default 1413 [3/18/2012 WangJinhui]  
  22.     printf(“Created %d threads\n”, i); return 0;  
  23. }